Ogni modifica a un sistema di produzione comporta conseguenze che vanno oltre il componente modificato. Una modifica a una funzione condivisa interrompe i chiamanti che dipendevano dal suo comportamento precedente. Una modifica allo schema del database invalida silenziosamente ogni query che faceva riferimento alla colonna modificata. Un aggiornamento del copybook COBOL richiede la ricompilazione di ogni programma che lo include, un'operazione che potrebbe coinvolgere centinaia di programmi in decine di flussi di lavoro, tutti da testare prima di qualsiasi passaggio in produzione. La domanda a cui risponde l'analisi d'impatto non è se una modifica abbia conseguenze, ma quali componenti siano esattamente interessati, come siano collegati all'elemento modificato e quale debba essere l'intera portata della validazione prima che la modifica possa essere implementata in sicurezza.
Individua gli errori di sincronizzazione prima che lo facciano gli utenti
SMART TS XL Mappa ogni relazione tra i dati, consentendo al tuo team di individuare i problemi di qualità prima che si ripercuotano sui risultati di ricerca.
Saperne di piùSenza un'analisi d'impatto, a questa domanda si risponde per tentativi, chiedendo allo sviluppatore che ha apportato la modifica, eseguendo l'intera suite di test e sperando che gli errori si concentrino intorno agli elementi giusti, oppure implementando e scoprendo i componenti interessati quando gli utenti segnalano errori. Gli strumenti di analisi d'impatto sostituiscono le congetture con prove strutturali: analizzano il codice sorgente, mappano le dipendenze e generano un elenco dettagliato di ogni componente che verrà influenzato dalla modifica proposta. Gli strumenti trattati in questa guida spaziano dalle piattaforme di analisi statica ai motori di selezione dei test fino ai mappatori di dipendenze aziendali, ognuno dei quali affronta una diversa dimensione del problema dell'analisi d'impatto.
Che cos'è l'analisi d'impatto nell'ingegneria del software?
L'analisi d'impatto nell'ingegneria del software è il processo di identificazione di tutti i componenti di un sistema che sono direttamente o indirettamente influenzati da una modifica proposta. Risponde alla domanda: se modifico questo, cos'altro cambierà? Opera prima dell'implementazione, durante la pianificazione, la progettazione e l'approvazione delle modifiche, piuttosto che a posteriori, durante i test o la gestione degli incidenti.
Il termine comprende diverse attività correlate ma distinte, che differiscono per ciò che analizzano e per il momento in cui vengono svolte:
L'analisi dell'impatto delle modifiche determina la portata di una modifica al codice proposta prima che venga implementata. Identifica quali moduli, funzioni, tabelle di database e sistemi dipendenti dovranno essere modificati o ritestati in seguito alla modifica proposta.
L'analisi dell'impatto dei test (TIA) è un'applicazione specifica dell'analisi dell'impatto delle modifiche che identifica quali test esistenti sono rilevanti per una determinata modifica del codice. Invece di eseguire l'intera suite di test, la TIA seleziona il sottoinsieme minimo di test che coprono il codice modificato e le sue dipendenze, riducendo i tempi di esecuzione dei test pur mantenendo la copertura dell'ambito interessato.
L'analisi dell'impatto dei requisiti identifica quali requisiti, elementi di progettazione e prodotti derivati vengono influenzati da una modifica dei requisiti. Nei settori regolamentati, ciò garantisce che ogni artefatto derivante da un requisito modificato venga aggiornato e riverificato.
Tutti e tre condividono un fondamento comune: un modello di dipendenza che rappresenta il modo in cui i componenti si relazionano tra loro e un meccanismo per attraversare tale modello a partire da un punto iniziale (il componente modificato) per enumerare tutto ciò che è raggiungibile da esso.
I tre tipi di analisi d'impatto
Le tecniche di analisi d'impatto si classificano in base al modo in cui raccolgono le informazioni sulla dipendenza:
| Tipo | Metodo | Cosa scopre | Quando usare |
|---|---|---|---|
| analisi d'impatto statico | Analizza il codice sorgente senza eseguirlo. | Tutti i riferimenti sintattici: chiamate di funzione, importazioni, accessi ai campi, riferimenti allo schema | Prima dell'implementazione, durante la pianificazione delle modifiche; funziona su qualsiasi codebase |
| Analisi dinamica dell'impatto | Strumenti che eseguono codice per osservare i percorsi di esecuzione effettivi | Solo i componenti effettivamente sollecitati durante una prova | Dipendenze specifiche dell'ambiente di runtime; identifica percorsi che l'analisi statica potrebbe non rilevare. |
| Basato sui requisiti (semantico) | Traccia i collegamenti di tracciabilità tra requisiti, progetti e codice. | Artefatti a monte e a valle interessati da una modifica dei requisiti | Settori regolamentati; ingegneria dei sistemi; software critico per la sicurezza |
L'analisi dell'impatto statico è la più utilizzata perché opera solo sul codice sorgente, senza richiedere un sistema in esecuzione o un'infrastruttura di test. È la tecnica utilizzata dagli strumenti in questa guida e da SMART TS XL Per l'analisi del codice sorgente aziendale, l'analisi dinamica integra l'analisi statica, catturando i comportamenti a runtime, come query costruite dinamicamente o chiamate a funzioni con collegamento dinamico, che l'analisi statica non è in grado di rilevare dal solo codice sorgente. In pratica, la maggior parte dei programmi di analisi dell'impatto in produzione combina entrambi gli approcci: l'analisi statica fornisce la mappa delle dipendenze di base, mentre la profilazione dinamica la convalida rispetto al comportamento a runtime osservato.
Analisi d'impatto statica vs. dinamica: differenze principali
L'analisi statica dell'impatto è conservativa: può sovrastimare l'ambito interessato includendo dipendenze presenti nel codice ma mai utilizzate nella pratica. L'analisi dinamica dell'impatto è precisa per ciò che osserva, ma incompleta, in quanto rileva solo ciò che è stato effettivamente eseguito durante la sessione monitorata, tralasciando i percorsi che vengono eseguiti con input o configurazioni diverse. Per i sistemi di produzione, dove la completezza è più importante della precisione, l'analisi statica rappresenta l'opzione predefinita più sicura.
Il processo di analisi d'impatto: passo dopo passo
Un processo strutturato di analisi d'impatto segue una sequenza coerente, indipendentemente dallo strumento utilizzato:
Passaggio 1: Definire la modifica. Identificare con precisione cosa sta cambiando: la funzione, il campo, la classe, il modulo, il copybook o la colonna del database specifici. La precisione in questa fase determina l'accuratezza di tutto ciò che segue. Definizioni vaghe delle modifiche ("stiamo modificando il modulo di pagamento") producono risultati di impatto vaghi.
Fase 2: Costruire o interrogare il modello delle dipendenze. Il modello delle dipendenze rappresenta le relazioni tra tutti i componenti del sistema. Per gli strumenti automatizzati, questo modello viene costruito analizzando il codice sorgente. Per l'analisi manuale su sistemi di piccole dimensioni, può essere mantenuto come documentazione. Il modello deve essere aggiornato: una documentazione obsoleta sulle dipendenze produce valutazioni d'impatto imprecise.
Passaggio 3: Attraversare il grafo delle dipendenze a partire dal punto di modifica. Partendo dal componente modificato, seguire tutti gli archi di dipendenza entranti (componenti che dipendono dal componente modificato) e gli archi uscenti (componenti da cui dipende il componente modificato, che potrebbero comportarsi in modo diverso dopo la modifica). Continuare in modo transitivo fino a quando non sono stati enumerati tutti i componenti dipendenti raggiungibili.
Fase 4: Classificare i componenti interessati in base al rischio. Non tutti i componenti interessati presentano lo stesso rischio. Un componente che richiama direttamente una funzione modificata presenta un rischio maggiore rispetto a uno che si trova a cinque livelli di dipendenza di distanza. Classificare i risultati in base alla prossimità, alla criticità e alla copertura dei test per focalizzare gli sforzi di correzione.
Fase 5: Definire l'ambito del test. L'insieme di impatto, ovvero l'elenco completo dei componenti interessati, definisce l'ambito minimo del test. Qualsiasi componente nell'insieme di impatto privo di copertura di test automatizzati rappresenta un rischio che deve essere affrontato aggiungendo test o mediante convalida manuale.
Fase 6: Documentazione e revisione. Presentare la valutazione d'impatto al comitato consultivo per le modifiche (CAB) o alle parti interessate pertinenti come base per l'approvazione della modifica. L'ambito d'impatto specificato con classificazione del rischio sostituisce le stime dello sviluppatore con prove strutturali.
Analisi dell'impatto dei test: come funziona nella CI/CD
L'analisi dell'impatto dei test (TIA) applica l'analisi d'impatto specificamente al problema del testing: data una modifica al codice, quali test devono essere eseguiti? Senza TIA, le pipeline CI eseguono l'intera suite di test a ogni commit. In una codebase con 50,000 test e una suite di test che richiede 45 minuti per essere eseguita, ciò significa che ogni pull request si blocca per 45 minuti, motivo per cui gli sviluppatori aggirano il problema, inviano più commit senza attendere i risultati e perdono il ciclo di feedback che il testing dovrebbe fornire.
TIA risolve questo problema tracciando la mappatura tra codice e test: quali righe di codice sono coperte da quali test. Quando un commit modifica righe specifiche, TIA seleziona solo i test che coprono quelle righe e le loro dipendenze. Una modifica che interessa tre file su 50,000 potrebbe richiedere 200 test anziché 50,000. La pipeline viene eseguita in secondi anziché in minuti.
La mappatura viene creata strumentando l'esecuzione dei test per registrare i dati di copertura, quindi memorizzando tali dati di copertura indicizzati dal codice che coprono. Ad ogni nuovo commit, TIA:
- Identifica quali file e funzioni sono stati modificati (tramite git diff).
- Cerca quali test riguardano quei file e quelle funzioni
- Aggiunge test che coprono ogni componente nel grafico delle dipendenze statiche del codice modificato
- Esegue il sottoinsieme selezionato; supera tutti i test rimanenti in quanto si presume non influenzato
Tra gli strumenti che implementano TIA figurano Test Impact Analysis di Microsoft in Visual Studio, il motore TIA di Parasoft, la selezione dei test di Gradle e diversi plugin integrati con CI per Jest, pytest e altri test runner. L'accuratezza di TIA dipende dall'accuratezza del modello di dipendenza: uno strumento che traccia solo la copertura diretta del codice senza attraversare le dipendenze non rileverà i test che coprono componenti distanti tre livelli dalla modifica.
TIA in pratica: prima e dopo
In un tipico servizio backend aziendale, l'abilitazione di TIA riduce il tempo di esecuzione dei test del 60-80% per una pull request media. Il compromesso è che modifiche molto ampie, come quelle che interessano utility condivise, classi base o configurazioni ampiamente utilizzate, potrebbero comunque generare grandi sottoinsiemi di test. TIA offre il massimo valore per lo sviluppo di nuove funzionalità e la correzione di bug, dove le modifiche sono localizzate. Per modifiche trasversali, come aggiornamenti del framework o modifiche allo schema condiviso, un'esecuzione completa dei test rimane la scelta più sicura.
Analisi d'impatto nella gestione dei requisiti e delle modifiche
Nell'ingegneria dei sistemi e nello sviluppo di software regolamentato, l'analisi d'impatto si estende oltre il codice, abbracciando l'intera catena di artefatti: requisiti, specifiche di progettazione, casi di test, valutazioni del rischio e prove di verifica. Un requisito modificato non influisce solo sul codice, ma su ogni elemento di progettazione che lo ha implementato, su ogni caso di test che lo ha verificato, su ogni valutazione del rischio che lo ha presupposto e su ogni documento di conformità che vi ha fatto riferimento.
L'analisi d'impatto basata sui requisiti utilizza collegamenti di tracciabilità per enumerare questo ambito a valle. Una matrice di tracciabilità che collega ciascun requisito ai relativi elementi di progettazione di implementazione, casi di test e prove di verifica consente di identificare l'intero ambito di riverifica richiesto da qualsiasi modifica dei requisiti. Nei settori regolamentati, come i dispositivi medici ai sensi della norma FDA 21 CFR Parte 11, il software aeronautico ai sensi della norma DO-178C e il software automobilistico ai sensi della norma ISO 26262, questo ambito di riverifica è un requisito normativo, non una pratica di qualità facoltativa.
Il collegamento tra l'analisi dell'impatto dei requisiti e l'analisi dell'impatto del codice è la tracciabilità: quando un requisito è riconducibile a uno specifico componente software, e tale componente viene identificato in un'analisi dell'impatto a livello di codice, i risultati dell'analisi dell'impatto possono essere utilizzati per concentrare l'attività di riverifica sui casi di test specifici che verificano quel componente. Le moderne piattaforme di gestione dei requisiti, tra cui Jama Connect e IBM DOORS, supportano questa tracciabilità e offrono funzionalità integrate di analisi dell'impatto a livello di requisiti.
Analisi d'impatto per codebase di grandi dimensioni e legacy
L'analisi d'impatto su codebase di grandi dimensioni, in particolare sistemi aziendali cresciuti nel corso di decenni, è qualitativamente diversa dall'analisi d'impatto su un servizio di 10,000 righe. Le differenze di scala non sono solo quantitative. Le grandi codebase legacy presentano strutture di dipendenza che nessun membro del team comprende appieno: migliaia di programmi con accoppiamento implicito tramite dataset condivisi, copybook inclusi simultaneamente da centinaia di programmi, flussi di job JCL con complesse logiche di esecuzione condizionale che creano dipendenze solo in fase di runtime.
Diverse caratteristiche delle grandi basi di codice rendono inaffidabile l'analisi manuale dell'impatto:
Dipendenze implicite. Nei sistemi COBOL, un copybook incluso da 300 programmi crea una dipendenza invisibile a qualsiasi sviluppatore che non sappia di doverla cercare. Una modifica a un membro del copybook che appare come una ridenominazione di un campo potrebbe richiedere la ricompilazione e il ritest di tutti e 300 i programmi. Senza un'analisi automatizzata, questa problematica viene scoperta progressivamente e ogni nuovo errore rivela un'altra dipendenza non rilevata.
Dipendenze tra linguaggi diversi. Un programma COBOL scrive in una tabella DB2. Un servizio Java legge dalla stessa tabella. Una pipeline Python elabora l'output del servizio Java. Una modifica allo schema DB2 influisce su tutti e tre i livelli. Nessuno strumento di analisi statica monolingue è in grado di tracciare questa catena di dipendenze tra linguaggi diversi; è necessario uno strumento che comprenda e colleghi tutti e tre i linguaggi in un modello di dipendenza unificato.
Dipendenze indirette tramite dati. Due programmi che non si chiamano mai a vicenda possono comunque essere accoppiati tramite un file condiviso. Il programma A scrive nel Dataset X; il programma B legge dal Dataset X. Una modifica alla struttura del Dataset X influisce su entrambi, ma la dipendenza non è una chiamata di funzione, bensì un contratto dati espresso tramite istruzioni JCL DD e definizioni COBOL FD. L'analisi strutturale che traccia solo le chiamate di funzione non rileva affatto questa classe di dipendenze.
Codice morto e raggiungibilità. Le codebase di grandi dimensioni accumulano codice definito ma mai chiamato, funzioni residue di funzionalità rimosse, procedure che sono state sostituite ma non eliminate. Un'analisi d'impatto che includa il codice morto nell'ambito interessato sovrastima la portata della modifica e indirizza gli sforzi di test verso componenti che non verranno mai raggiunti in produzione.
La soluzione di analisi per la modernizzazione dei sistemi legacy in questi ambienti deve gestire tutti questi casi: deve analizzare i linguaggi effettivamente utilizzati (inclusi COBOL, JCL, PL/I, RPG, Assembler e DB2), risolvere le dipendenze implicite attraverso strutture dati condivise, tracciare le catene di dipendenze tra linguaggi diversi e distinguere il codice raggiungibile da quello irraggiungibile.
Strumenti di analisi d'impatto: un confronto tra
Gli strumenti elencati di seguito coprono le principali categorie di analisi d'impatto nello sviluppo software. Ciascuno viene valutato in base a ciò che analizza, ai linguaggi supportati e alla tipologia di problema di analisi d'impatto che affronta meglio.
| Chiavetta | Approccio primario | Lingue disponibili | Ideale per |
|---|---|---|---|
| SMART TS XL | Mappatura statica e interlinguistica delle dipendenze | COBOL, JCL, Java, Python, .NET, RPG, SQL | Analisi dell'impatto multilingue su sistemi aziendali e mainframe |
| Capire con SciTools | Analisi statica, grafici delle chiamate, visualizzazione delle dipendenze | 70+ lingue | Insiemi di comprensione del codice multilingue e di impatto |
| Struttura101 | Analisi dell'architettura, grafici delle dipendenze | Java, C#, JVM/.NET | Impatto strutturale nelle applicazioni aziendali Java/C# |
| CAST AIP | Intelligence applicativa, debito tecnico, impatto | Java, .NET, COBOL, SQL | Analisi dell'impatto commerciale e tecnico a livello di portafoglio |
| Suite Axivion | Grafi di dipendenza semantica per C/C++ | C, C ++ | Sistemi critici per la sicurezza, conformità MISRA, sistemi integrati |
| Parasoft | Analisi dell'impatto dei test, integrazione CI/CD | Java, C/C++, .NET | TIA nei settori regolamentati, test critici per la sicurezza |
| Jama Connect | Tracciabilità dei requisiti, impatto degli artefatti | Indipendente dal linguaggio (livello dei requisiti) | Ingegneria dei sistemi, settori regolamentati, DO-178C/ISO 26262 |
| soundQube | Qualità del codice, analisi delle dipendenze all'interno di un linguaggio | 30+ lingue | Controlli di qualità del codice; analisi limitata dell'impatto intersistemico |
| IntelliJ IDEA / Eclipse | Gerarchia delle chiamate IDE, analisi dei riferimenti | Java, Kotlin, Python | Analisi dell'impatto locale a livello di sviluppatore all'interno di un progetto |
Understand di SciTools è lo strumento di analisi d'impatto più completo e dedicato per i team di sviluppo software che lavorano con linguaggi moderni. La sua funzionalità Impact Sets calcola la chiusura transitiva di tutte le entità di codice interessate da una specifica modifica, ovvero ogni funzione, classe e variabile raggiungibile attraverso il grafo delle dipendenze a partire dal punto di partenza. Supporta oltre 70 linguaggi e produce grafici di chiamate dettagliati, diagrammi di flusso dati e mappe delle relazioni tra entità.
Structure101 è lo strumento più potente per l'analisi dell'impatto a livello di architettura in Java e C#. Visualizza la struttura delle dipendenze di pacchetti e classi come mappe interattive e identifica i punti in cui le modifiche proposte violano i confini architetturali o creano nuovi cicli nel grafo delle dipendenze.
CAST AIP opera a livello di portfolio, analizzando l'intero panorama applicativo, inclusi COBOL, Java, .NET, SQL e altri linguaggi, per produrre punteggi di impatto aziendale insieme all'analisi dell'impatto tecnico. Viene comunemente utilizzato nelle attività di due diligence in ambito M&A e nei programmi di razionalizzazione del portfolio.
Axivion Suite è pensato per lo sviluppo di applicazioni C e C++ critiche per la sicurezza, dove l'analisi d'impatto deve soddisfare i requisiti normativi (ISO 26262, DO-178C, MISRA) e produrre una prova formale della completezza dell'analisi.
Parasoft è la soluzione TIA più potente per i settori regolamentati, con un motore di selezione dei test integrato con CI/CD che traccia la copertura fino al livello di singola istruzione e seleziona i sottoinsiemi di test in base a un'analisi precisa delle dipendenze.
SonarQube offre analisi delle dipendenze interne al progetto e rilevamento di "code smell" (cattive pratiche di programmazione), ma non è progettato per analisi di impatto tra sistemi o linguaggi di programmazione diversi. Il suo valore, nell'ambito dell'analisi di impatto, risiede nella sua funzione di controllo qualità, che identifica quali componenti modificati introducono nuovi problemi di qualità o sicurezza, piuttosto che nella sua funzione di mappatura delle dipendenze.
Gli strumenti basati su IDE (gerarchia delle chiamate di IntelliJ, analisi dei riferimenti di Visual Studio, grafico delle chiamate di Eclipse) forniscono agli sviluppatori un'analisi dell'impatto locale all'interno di un progetto. Sono efficaci per comprendere gli effetti di una modifica all'interno di un modulo, ma non possono tracciare le dipendenze tra progetti, linguaggi o sistemi mainframe.
Come SMART TS XL Esegue un'analisi d'impatto
SMART TS XL Esegue un'analisi d'impatto analizzando ogni file sorgente presente nell'ambiente, programmi COBOL, flussi di lavoro JCL, copybook, schemi SQL, classi Java, moduli Python, programmi RPG e altri, e costruendo un modello di dipendenza unificato che rappresenta tutte le relazioni strutturali tra tutti i linguaggi. Questo modello è il fondamento: l'analisi d'impatto consiste in una query su di esso, partendo da qualsiasi componente e attraversando il grafo delle dipendenze per enumerare tutto ciò che è interessato.
Quando un team propone di modificare un membro del copybook COBOL, SMART TS XL'S analisi d'impatto Risposte: quali programmi includono questo copybook? Di questi programmi, quali vengono richiamati da quali passaggi del job JCL? Quali tabelle DB2 leggono o scrivono questi programmi? Quali servizi Java utilizzano queste tabelle? Quali casi di test coprono questi programmi? La risposta non è una stima, ma un elenco completo e dettagliato derivato dalla struttura effettiva del codice, con nomi di file, nomi di programmi, nomi di job e numeri di riga.
La funzionalità di mappatura delle dipendenze dell'applicazione genera diagrammi visivi del grafo delle dipendenze centrati sul componente modificato, utilizzando una codifica a colori per distinguere le dipendenze dirette da quelle indirette e per evidenziare le connessioni a più alto rischio. Questi diagrammi fungono da base di prova per la revisione del CAB (Customer Advisory Board) e da guida per la pianificazione dei test.
La funzionalità di espansione JCL risolve la sostituzione simbolica dei parametri nelle PROC prima dell'analisi, garantendo che il modello di dipendenza rifletta l'effettiva esecuzione a runtime anziché riferimenti a modelli non risolti. Una PROC che richiama programmi diversi a seconda dei parametri simbolici viene risolta in tutti i programmi che effettivamente richiama da tutti i suoi chiamanti, una copertura completa che gli strumenti non compatibili con i parametri simbolici non riescono a raggiungere.
Per i team aziendali che conducono la due diligence tecnica, pianificano la modernizzazione dei sistemi legacy o gestiscono il cambiamento in sistemi che si estendono su più lingue e piattaforme, SMART TS XL'S ricerca aziendale Questa funzionalità rende il modello di dipendenza interrogabile: permette di trovare in pochi secondi ogni utilizzo di un campo specifico, ogni programma che chiama una funzione specifica, ogni job JCL che produce un dataset specifico, in una codebase di qualsiasi dimensione.
Analisi d'impatto: migliori pratiche
L'analisi d'impatto va avviata prima di scrivere il codice, non dopo. Lo scopo dell'analisi d'impatto è quello di supportare la decisione di apportare una modifica e di definire l'ambito del lavoro risultante, non di spiegare cosa si è rotto dopo l'implementazione. Una valutazione d'impatto prodotta dopo che una modifica è già in corso è una razionalizzazione a posteriori, non uno strumento di pianificazione.
Definisci esplicitamente i confini della valutazione d'impatto. I grafici d'impatto in sistemi di grandi dimensioni possono arrivare a includere quasi tutto. Definisci i confini dell'analisi, la profondità massima delle dipendenze, il codice morto escluso e i sistemi fuori ambito prima di eseguire l'analisi. Un'attraversata non vincolata produce risultati tecnicamente corretti ma operativamente inutili.
È importante distinguere tra "da ritestare assolutamente" e "da monitorare assolutamente". Non tutti i componenti del set di impatto richiedono la stessa risposta in fase di test. Un componente che chiama direttamente la funzione modificata in un percorso critico deve essere ritestato. Un componente che raggiunge la funzione modificata attraverso cinque livelli di codice raramente eseguito può essere monitorato in produzione. La classificazione del rischio trasforma un elenco di impatto in un piano di test.
Mantieni aggiornato il modello delle dipendenze. Un'analisi d'impatto eseguita su un modello delle dipendenze obsoleto o incompleto è peggio di nessuna analisi d'impatto, perché genera una falsa sicurezza in un ambito errato. I modelli delle dipendenze devono essere rigenerati a ogni modifica significativa al codice sorgente o aggiornati in modo incrementale tramite un'integrazione CI/CD che rianalighi automaticamente i file modificati.
Abbina l'analisi d'impatto al controllo delle modifiche. L'analisi d'impatto esprime tutto il suo valore quando i suoi risultati confluiscono in un processo formale di controllo delle modifiche. Un report d'impatto che documenti l'ambito, la classificazione del rischio e i requisiti di test fornisce ai comitati consultivi per le modifiche le prove strutturali necessarie per prendere decisioni di autorizzazione basate sul sistema reale, anziché sulle stime degli sviluppatori.
Per i sistemi legacy, è necessario tenere conto dell'accoppiamento implicito dei dati. Qualsiasi analisi delle dipendenze per un sistema legacy che si limiti a tracciare le chiamate di funzione è incompleta. I programmi accoppiati tramite file condivisi, dataset, database e code di messaggi sono comuni negli ambienti mainframe e risultano invisibili a un'analisi basata esclusivamente sulle chiamate di funzione. Il modello di dipendenza deve tenere conto dell'accoppiamento a livello di dati per produrre una valutazione completa dell'impatto.
L'investimento in infrastrutture di analisi d'impatto, sia attraverso uno strumento dedicato come SMART TS XLUn motore di analisi dell'impatto dei test come Parasoft, o una piattaforma di tracciabilità dei requisiti come Jama, recuperano i costi attraverso le modifiche che non hanno causato problemi imprevisti, i test che non hanno richiesto l'esecuzione dell'intera suite e le implementazioni che non hanno prodotto incidenti. Tale recupero non è ipotetico. Ogni incidente di produzione causato da una dipendenza non rilevata rappresenta un costo diretto dell'analisi che non è stata effettuata prima della modifica.
