Cada cambio en un sistema de producción conlleva consecuencias que van más allá del componente modificado. Una modificación en una función compartida afecta a los programas que dependían de su comportamiento anterior. Un cambio en el esquema de la base de datos invalida silenciosamente todas las consultas que hacían referencia a la columna modificada. Una actualización de un copybook de COBOL requiere recompilar todos los programas que la incluyen, un alcance que puede abarcar cientos de programas en docenas de flujos de trabajo, los cuales deben probarse antes de cualquier puesta en producción. La pregunta que responde el análisis de impacto no es si un cambio tiene consecuencias, sino exactamente qué componentes se ven afectados, cómo están conectados al elemento modificado y cuál debe ser el alcance completo de la validación antes de que el cambio se pueda implementar de forma segura.
Detecta los fallos de sincronización antes de que los usuarios lo hagan.
SMART TS XL Mapea todas las relaciones de datos para que tu equipo detecte los fallos de calidad antes de que lleguen a los resultados de búsqueda.
Aprende másSin un análisis de impacto, esa pregunta se responde adivinando, preguntando al desarrollador que realizó el cambio, ejecutando el conjunto completo de pruebas con la esperanza de que los fallos se agrupen en torno a los elementos correctos, o desplegando y descubriendo los componentes afectados cuando los usuarios informan de fallos. Las herramientas de análisis de impacto sustituyen las adivinanzas por evidencia estructural: analizan el código fuente, mapean las dependencias y generan una lista enumerada de todos los componentes que se verán afectados por el cambio propuesto. Las herramientas que se describen en esta guía abarcan desde plataformas de análisis estático hasta motores de selección de pruebas y mapeadores de dependencias empresariales, cada una de las cuales cubre una dimensión diferente del problema del análisis de impacto.
¿Qué es el análisis de impacto en la ingeniería de software?
El análisis de impacto en la ingeniería de software consiste en identificar todos los componentes de un sistema que se ven afectados, directa o indirectamente, por un cambio propuesto. Responde a la pregunta: si modifico esto, ¿qué más cambia? Se realiza antes de la implementación, durante la planificación, el diseño y la aprobación del cambio, en lugar de a posteriori, durante las pruebas o la respuesta a incidentes.
El término abarca varias actividades relacionadas pero distintas que difieren en lo que analizan y en cuándo lo hacen:
Análisis de impacto de cambios Determina el alcance de un cambio de código propuesto antes de que se realice. Identifica qué módulos, funciones, tablas de base de datos y sistemas dependientes deberán modificarse o volver a probarse como consecuencia del cambio propuesto.
Análisis de impacto de pruebas (TIA) Se trata de una aplicación específica del análisis de impacto de cambios que identifica qué pruebas existentes son relevantes para un cambio de código determinado. En lugar de ejecutar el conjunto completo de pruebas, TIA selecciona el subconjunto mínimo de pruebas que cubren el código modificado y sus dependencias, lo que reduce el tiempo de ejecución de las pruebas y mantiene la cobertura del ámbito afectado.
Análisis del impacto de los requisitos Identifica qué requisitos, elementos de diseño y entregables posteriores se ven afectados cuando cambia un requisito. En industrias reguladas, esto garantiza que cada artefacto posterior que dependa de un requisito modificado se actualice y se vuelva a verificar.
Los tres comparten una base común: un modelo de dependencia que representa cómo se relacionan los componentes entre sí, y un mecanismo para recorrer ese modelo desde un punto de partida (el componente modificado) para enumerar todo lo que se puede alcanzar desde él.
Los tres tipos de análisis de impacto
Las técnicas de análisis de impacto se clasifican según cómo recopilan información sobre las dependencias:
| Tipo | Método | Lo que encuentra | Cuándo usar |
|---|---|---|---|
| Análisis de impacto estático | Analiza el código fuente sin ejecutarlo. | Todas las referencias sintácticas: llamadas a funciones, importaciones, accesos a campos, referencias a esquemas. | Antes de la implementación, durante la planificación del cambio; funciona en cualquier base de código. |
| Análisis de impacto dinámico | Instrumentos que ejecutan código para observar las rutas de ejecución reales. | Solo se utilizaron los componentes que se pusieron en práctica durante la prueba. | Dependencias específicas del entorno de ejecución; identifica rutas que el análisis estático podría pasar por alto. |
| Basado en requisitos (semántico) | Registra los vínculos de trazabilidad entre los requisitos, los diseños y el código. | Artefactos ascendentes y descendentes afectados por un cambio de requisitos | Industrias reguladas; ingeniería de sistemas; software crítico para la seguridad |
El análisis de impacto estático es el más utilizado porque opera únicamente sobre el código fuente, sin requerir un sistema en funcionamiento ni una infraestructura de prueba. Es la técnica utilizada por las herramientas de esta guía y por SMART TS XL Para el análisis de la base de código empresarial, el análisis dinámico complementa el análisis estático al capturar comportamientos en tiempo de ejecución, como consultas construidas dinámicamente o llamadas a funciones de enlace tardío, que el análisis estático no puede resolver solo a partir del código fuente. En la práctica, la mayoría de los programas de análisis de impacto en producción combinan ambos: el análisis estático proporciona el mapa de dependencias de referencia y el perfilado dinámico lo valida comparándolo con el comportamiento observado en tiempo de ejecución.
Análisis de impacto estático frente a dinámico: diferencias clave
El análisis de impacto estático es conservador: puede sobreestimar el alcance afectado al incluir dependencias que existen en el código pero que nunca se utilizan en la práctica. El análisis de impacto dinámico es preciso en lo que observa, pero incompleto; solo registra lo que se ejecutó durante la sesión instrumentada, omitiendo rutas que se ejecutan con diferentes entradas o configuraciones. Para sistemas de producción donde la exhaustividad es más importante que la precisión, el análisis estático es la opción predeterminada más segura.
El proceso de análisis de impacto: paso a paso
Un proceso estructurado de análisis de impacto sigue una secuencia consistente independientemente de la herramienta utilizada:
Paso 1: Definir el cambio. Identifique con precisión qué es lo que cambia: la función, el campo, la clase, el módulo, el archivo de copia o la columna de la base de datos específicos. La precisión en este paso determina la exactitud de todo lo que sigue. Las definiciones de cambio vagas («estamos modificando el módulo de pagos») generan resultados de impacto imprecisos.
Paso 2: Construir o consultar el modelo de dependencias. El modelo de dependencias representa las relaciones entre todos los componentes del sistema. Para herramientas automatizadas, este modelo se construye analizando el código fuente. Para análisis manuales en sistemas pequeños, puede mantenerse como documentación. El modelo debe estar actualizado: la documentación de dependencias obsoleta produce evaluaciones de impacto inexactas.
Paso 3: Recorra el grafo de dependencias desde el punto de cambio. Partiendo del componente modificado, siga todas las aristas de dependencia entrantes (componentes que dependen del componente modificado) y salientes (componentes de los que depende el componente modificado, que pueden comportarse de manera diferente después del cambio). Continúe de forma transitiva hasta que se hayan enumerado todos los componentes dependientes alcanzables.
Paso 4: Clasifique los componentes afectados según su riesgo. No todos los componentes afectados conllevan el mismo riesgo. Un componente que llama directamente a una función modificada presenta un riesgo mayor que uno que se encuentra a cinco niveles de dependencia de distancia. Clasifique los hallazgos por proximidad, criticidad y cobertura de pruebas para enfocar los esfuerzos de remediación.
Paso 5: Definir el alcance de la prueba. El conjunto de impacto, la lista completa de componentes afectados, define el alcance mínimo de las pruebas. Cualquier componente del conjunto de impacto que carezca de cobertura de pruebas automatizadas representa un riesgo que debe abordarse mediante la adición de pruebas o mediante la validación manual.
Paso 6: Documentar y revisar. Presente la evaluación de impacto al comité asesor de cambios (CAB) o a las partes interesadas pertinentes como base para la aprobación del cambio. El alcance del impacto enumerado, con su clasificación de riesgos, reemplaza las estimaciones de los desarrolladores con evidencia estructural.
Análisis del impacto de las pruebas: cómo funciona en CI/CD
El análisis de impacto de pruebas (TIA) aplica el análisis de impacto específicamente al problema de las pruebas: dado un cambio en el código, ¿qué pruebas deben ejecutarse? Sin TIA, las canalizaciones de CI ejecutan el conjunto completo de pruebas en cada confirmación. En una base de código con 50 000 pruebas y un conjunto de pruebas que tarda 45 minutos en ejecutarse, esto significa que cada solicitud de extracción se bloquea durante 45 minutos, razón por la cual los desarrolladores la evitan, envían múltiples confirmaciones sin esperar los resultados y pierden el ciclo de retroalimentación que se supone que proporcionan las pruebas.
TIA resuelve este problema rastreando la correspondencia entre el código y las pruebas: qué líneas de código están cubiertas por qué pruebas. Cuando una confirmación modifica líneas específicas, TIA selecciona solo las pruebas que cubren esas líneas y sus dependencias. Un cambio que afecta a tres archivos de un total de 50 000 podría requerir 200 pruebas en lugar de 50 000. El proceso se ejecuta en segundos en lugar de minutos.
El mapeo se construye instrumentando la ejecución de pruebas para registrar datos de cobertura y luego almacenando esos datos de cobertura indexados por el código que cubren. En cada nueva confirmación, TIA:
- Identifica qué archivos y funciones cambiaron (a partir de la diferencia de Git).
- Busca qué pruebas cubren esos archivos y funciones.
- Agrega pruebas que cubren cualquier componente en el gráfico de dependencias estáticas del código modificado.
- Ejecuta el subconjunto seleccionado; supera todas las pruebas restantes como si no se hubiera visto afectado.
Entre las herramientas que implementan TIA se incluyen el Análisis de Impacto de Pruebas (TIA) de Microsoft en Visual Studio, el motor TIA de Parasoft, la selección de pruebas de Gradle y varios complementos integrados con CI para Jest, pytest y otros ejecutores de pruebas. La precisión de TIA depende de la precisión del modelo de dependencias; una herramienta que solo rastrea la cobertura directa del código sin recorrer las dependencias no detectará las pruebas que cubren componentes a tres niveles de distancia del cambio.
AIT en la práctica: antes y después
En un servicio backend empresarial típico, habilitar TIA reduce el tiempo de ejecución de pruebas entre un 60 % y un 80 % en una solicitud de extracción promedio. La desventaja es que los cambios muy grandes, aquellos que afectan a utilidades compartidas, clases base o configuraciones de uso generalizado, aún pueden activar grandes subconjuntos de pruebas. TIA ofrece el mayor valor para el desarrollo de nuevas funcionalidades y la corrección de errores, donde los cambios son localizados. Para cambios transversales, como actualizaciones de frameworks o modificaciones de esquemas compartidos, una ejecución completa de pruebas sigue siendo la opción más segura.
Análisis de impacto en la gestión de requisitos y cambios
En la ingeniería de sistemas y el desarrollo de software regulado, el análisis de impacto se extiende más allá del código y abarca toda la cadena de artefactos: requisitos, especificaciones de diseño, casos de prueba, evaluaciones de riesgos y evidencia de verificación. Un requisito modificado no solo afecta al código, sino también a cada elemento de diseño que lo implementó, a cada caso de prueba que lo verificó, a cada evaluación de riesgos que lo asumió y a cada documento de cumplimiento que lo menciona.
El análisis de impacto basado en requisitos utiliza enlaces de trazabilidad para enumerar este alcance descendente. Una matriz de trazabilidad que conecta cada requisito con sus elementos de diseño de implementación, casos de prueba y evidencia de verificación permite identificar el alcance completo de la reverificación requerida por cualquier cambio de requisito. En industrias reguladas, como los dispositivos médicos según la norma FDA 21 CFR Parte 11, el software de aviación según la norma DO-178C y el software automotriz según la norma ISO 26262, este alcance de reverificación es un requisito reglamentario, no una práctica de calidad opcional.
La conexión entre el análisis de impacto de requisitos y el análisis de impacto de código radica en la trazabilidad: cuando un requisito se relaciona con un componente de software específico, y dicho componente se identifica en un análisis de impacto a nivel de código, los resultados de este análisis pueden utilizarse para enfocar el esfuerzo de reverificación en los casos de prueba específicos que verifican ese componente. Las plataformas modernas de gestión de requisitos, como Jama Connect e IBM DOORS, admiten esta trazabilidad y ofrecen capacidades integradas de análisis de impacto a nivel de requisitos.
Análisis de impacto para bases de código grandes y heredadas
El análisis de impacto para grandes bases de código, en particular sistemas empresariales que han crecido durante décadas, es cualitativamente diferente al análisis de impacto para un servicio de 10 000 líneas. Las diferencias de escala no son solo cuantitativas. Las grandes bases de código heredadas tienen estructuras de dependencia que ningún miembro del equipo actual comprende completamente: miles de programas con acoplamiento implícito a través de conjuntos de datos compartidos, copybooks incluidos por cientos de programas simultáneamente, flujos de trabajos JCL con lógica de ejecución condicional compleja que crea dependencias solo en tiempo de ejecución.
Varias características de las grandes bases de código hacen que el análisis de impacto manual no sea fiable:
Dependencias implícitas. En los sistemas COBOL, un copybook incluido por 300 programas crea una dependencia invisible para cualquier desarrollador que no sepa cómo buscarla. Un cambio en un miembro del copybook que parezca un cambio de nombre de campo puede requerir recompilar y volver a probar los 300 programas. Sin un análisis automatizado, este problema se descubre progresivamente; cada nuevo fallo revela otra dependencia no detectada.
Dependencias entre idiomas. Un programa COBOL escribe en una tabla DB2. Un servicio Java lee de la misma tabla. Una canalización de Python procesa la salida del servicio Java. Un cambio en el esquema DB2 afecta a las tres capas. Ninguna herramienta de análisis estático de un solo lenguaje puede rastrear esta cadena entre lenguajes; se requiere una herramienta que comprenda y conecte los tres lenguajes en un modelo de dependencia unificado.
Dependencias indirectas a través de los datos. Dos programas que nunca se llaman entre sí pueden estar acoplados mediante un archivo compartido. El programa A escribe en el conjunto de datos X; el programa B lee del conjunto de datos X. Un cambio en la estructura del conjunto de datos X afecta a ambos, pero la dependencia no es una llamada a función, sino un contrato de datos expresado mediante sentencias DD de JCL y definiciones FD de COBOL. El análisis estructural que solo rastrea las llamadas a funciones no detecta este tipo de dependencia.
Código muerto y accesibilidad. Las bases de código extensas acumulan código definido pero nunca utilizado, funciones remanentes de características eliminadas y procedimientos reemplazados pero no borrados. Un análisis de impacto que incluya código obsoleto en el ámbito afectado sobreestima el alcance del cambio y dirige los esfuerzos de prueba hacia componentes que nunca se utilizarán en producción.
El modernización heredada La solución de análisis para estos entornos debe abarcar todos estos casos: debe analizar los lenguajes reales en uso (incluidos COBOL, JCL, PL/I, RPG, Assembler y DB2), resolver las dependencias implícitas a través de estructuras de datos compartidas, rastrear las cadenas entre lenguajes y distinguir el código accesible del inaccesible.
Herramientas de análisis de impacto: cómo se comparan
Las herramientas que se describen a continuación abarcan las principales categorías de análisis de impacto en el desarrollo de software. Cada una se evalúa según lo que analiza, los lenguajes que admite y el tipo de problema de análisis de impacto que mejor aborda.
| Enfoque primario | Idiomas | Uso recomendado | |
|---|---|---|---|
| SMART TS XL | Mapeo de dependencias estáticas y entre lenguajes | COBOL, JCL, Java, Python, .NET, RPG, SQL | Análisis de impacto multilingüe en empresas y sistemas centrales |
| Entender por SciTools | Análisis estático, gráficos de llamadas, visualización de dependencias. | 70+ idiomas | Conjuntos de comprensión e impacto de códigos multilingües |
| Estructura101 | Análisis de arquitectura, grafos de dependencia | Java, C#, JVM/.NET | Impacto estructural en aplicaciones empresariales Java/C# |
| REPARTO AIP | Inteligencia de aplicaciones, deuda técnica, impacto | Java, .NET, COBOL, SQL | Análisis del impacto empresarial y técnico a nivel de cartera |
| Suite Axivion | Grafos de dependencia semántica para C/C++ | C, C ++ | Sistemas críticos para la seguridad, cumplimiento de MISRA, integrados |
| parasoft | Análisis del impacto de las pruebas, integración de CI/CD | Java, C/C++, .NET | Análisis de impacto transaccional (TIA) en industrias reguladas, pruebas de seguridad crítica |
| jama conectar | Trazabilidad de requisitos, impacto de los artefactos | Independiente del idioma (nivel de requisitos) | Ingeniería de sistemas, industrias reguladas, DO-178C/ISO 26262 |
| SonarQube | Calidad del código, análisis de dependencias dentro de un lenguaje | 30+ idiomas | Controles de calidad del código; análisis de impacto entre sistemas limitado |
| IntelliJ IDEA / Eclipse | Jerarquía de llamadas del IDE, análisis de referencias | Java, Kotlin, Python | Análisis del impacto local a nivel de desarrollador dentro de un proyecto |
Entender por SciTools Es la herramienta de análisis de impacto más completa y especializada para equipos de software que trabajan con lenguajes modernos. Su función Conjuntos de Impacto calcula el cierre transitivo de todas las entidades de código afectadas por un cambio específico: cada función, clase y variable accesible a través del grafo de dependencias desde el punto de partida. Admite más de 70 lenguajes y genera grafos de llamadas detallados, diagramas de flujo de datos y mapas de relaciones entre entidades.
Estructura101 Es la herramienta más potente para el análisis de impacto a nivel de arquitectura en Java y C#. Visualiza la estructura de dependencias de paquetes y clases como mapas interactivos e identifica dónde los cambios propuestos infringen los límites arquitectónicos o crean nuevos ciclos en el grafo de dependencias.
REPARTO AIP Opera a nivel de cartera, analizando el panorama completo de aplicaciones, incluyendo COBOL, Java, .NET, SQL y otros lenguajes, para generar puntuaciones de impacto empresarial junto con un análisis de impacto técnico. Se utiliza habitualmente en procesos de due diligence de fusiones y adquisiciones y en programas de racionalización de carteras.
Suite Axivion Se centra en el desarrollo de aplicaciones críticas para la seguridad en C y C++, donde el análisis de impacto debe cumplir con los requisitos reglamentarios (ISO 26262, DO-178C, MISRA) y proporcionar evidencia formal de la exhaustividad del análisis.
parasoft Es la solución TIA más robusta para industrias reguladas, con un motor de selección de pruebas integrado con CI/CD que realiza un seguimiento de la cobertura hasta el nivel de instrucción y selecciona subconjuntos de pruebas en función de un recorrido preciso de las dependencias.
SonarQube Proporciona análisis de dependencias dentro del proyecto y detección de malas prácticas de código, pero no está diseñado para el análisis de impacto entre sistemas o lenguajes. Su valor en el análisis de impacto reside en su función como filtro de calidad, identificando qué componentes modificados introducen nuevos problemas de calidad o seguridad, más que en su función como mapeador de dependencias.
Herramientas basadas en IDE Las herramientas de análisis de impacto local (como la jerarquía de llamadas de IntelliJ, el análisis de referencias de Visual Studio y el gráfico de llamadas de Eclipse) permiten a los desarrolladores analizar el impacto de un cambio dentro de un proyecto. Son eficaces para comprender las consecuencias de un cambio en un módulo, pero no permiten rastrear dependencias entre proyectos, lenguajes o sistemas centrales.
Cómo SMART TS XL Realiza análisis de impacto
SMART TS XL Realiza un análisis de impacto analizando cada archivo fuente del entorno, programas COBOL, flujos de trabajo JCL, copybooks, esquemas SQL, clases Java, módulos Python, programas RPG y otros, y construyendo un modelo de dependencia unificado que representa todas las relaciones estructurales en todos los lenguajes. Este modelo es la base: el análisis de impacto es una consulta sobre él, que parte de cualquier componente y recorre el grafo de dependencias para enumerar todo lo afectado.
Cuando un equipo propone cambiar un miembro del copybook de COBOL, SMART TS XL, análisis de impacto Respuestas: ¿Qué programas incluyen este copybook? De esos programas, ¿cuáles son invocados por qué pasos de trabajo JCL? ¿Qué tablas de DB2 leen o escriben esos programas? ¿Qué servicios Java consumen esas tablas? ¿Qué casos de prueba cubren esos programas? La respuesta no es una estimación, sino una lista completa y enumerada derivada de la estructura real del código, con nombres de archivos, nombres de programas, nombres de trabajos y números de línea.
El mapeo de dependencias de aplicaciones La herramienta genera diagramas visuales del gráfico de dependencias centrado en el componente modificado, utilizando códigos de color para distinguir las dependencias directas de las indirectas y resaltar las conexiones de mayor riesgo. Estos diagramas sirven como base para la revisión del Comité de Aprobación de Cambios (CAB) y como guía para la planificación de las pruebas.
El Expansión JCL Esta capacidad resuelve la sustitución de parámetros simbólicos en los PROC antes del análisis, lo que garantiza que el modelo de dependencias refleje la ejecución real en tiempo de ejecución en lugar de referencias a plantillas sin resolver. Un PROC que invoca diferentes programas según parámetros simbólicos se resuelve para todos los programas que realmente invoca en todos sus llamadores, una cobertura completa que las herramientas que no reconocen parámetros simbólicos no pueden proporcionar.
Para los equipos empresariales que realizan la debida diligencia técnica, planifican la modernización de sistemas heredados o gestionan el cambio en sistemas que abarcan múltiples lenguajes y plataformas, SMART TS XL, búsqueda empresarial Esta capacidad permite consultar el modelo de dependencias: encuentre en segundos cada uso de un campo específico, cada programa que llama a una función específica, cada trabajo JCL que produce un conjunto de datos específico, en un código fuente de cualquier tamaño.
Mejores prácticas para el análisis de impacto
Comience el análisis de impacto antes de escribir el código, no después. El objetivo del análisis de impacto es fundamentar la decisión de realizar un cambio y definir el alcance del trabajo resultante, no explicar qué falló después de la implementación. Una evaluación de impacto realizada una vez que el cambio ya está en marcha es una justificación a posteriori, no una herramienta de planificación.
Defina explícitamente el alcance de la evaluación de impacto. En sistemas grandes, los gráficos de impacto pueden llegar a abarcar prácticamente todo. Antes de ejecutar el análisis, defina los límites del análisis, la profundidad máxima de dependencia, el código muerto excluido y los sistemas fuera del alcance. El recorrido sin restricciones produce resultados técnicamente correctos, pero prácticamente inútiles desde el punto de vista operativo.
Distinga entre repetir la prueba obligatoriamente y realizar un seguimiento recomendable. No todos los componentes del conjunto de impacto requieren la misma respuesta de prueba. Un componente que llama directamente a la función modificada en una ruta crítica debe volver a probarse. Un componente que accede a la función modificada a través de cinco niveles de código que se ejecuta con poca frecuencia puede supervisarse en producción. La clasificación de riesgos convierte una lista de impacto en un plan de pruebas.
Mantenga actualizado el modelo de dependencias. Un análisis de impacto realizado sobre un modelo de dependencias obsoleto o incompleto es peor que no realizar ningún análisis de impacto, ya que genera una falsa sensación de seguridad sobre un alcance incorrecto. Los modelos de dependencias deben regenerarse con cada cambio significativo en el código fuente o actualizarse de forma incremental mediante una integración de CI/CD que vuelva a analizar automáticamente los archivos modificados.
Combine el análisis de impacto con el control de cambios. El análisis de impacto alcanza su máximo valor cuando sus resultados se integran en un proceso formal de control de cambios. Un informe de impacto que documente el alcance, la clasificación de riesgos y los requisitos de prueba proporciona a los comités asesores de cambios la evidencia estructural necesaria para tomar decisiones de autorización basadas en el sistema real, en lugar de en estimaciones de los desarrolladores.
En el caso de sistemas heredados, tenga en cuenta el acoplamiento implícito de datos. Cualquier análisis de dependencias para un sistema heredado que solo rastree las llamadas a funciones es incompleto. Los programas acoplados mediante archivos compartidos, conjuntos de datos, bases de datos y colas de mensajes son comunes en entornos de mainframe y resultan invisibles para un análisis que solo se base en llamadas a funciones. El modelo de dependencias debe tener en cuenta el acoplamiento a nivel de datos para generar un alcance de impacto completo.
La inversión en infraestructura de análisis de impacto, ya sea a través de una herramienta dedicada como SMART TS XLEl coste de un motor de análisis de impacto de pruebas como Parasoft o una plataforma de trazabilidad de requisitos como Jama se recupera mediante los cambios que no provocaron fallos inesperados, las pruebas que no requirieron la ejecución de la suite completa y las implementaciones que no generaron incidentes. Esta recuperación no es hipotética. Cada incidente de producción causado por una dependencia no detectada supone un coste directo del análisis que no se realizó antes de implementar el cambio.
