Perché una piccola modifica al software può richiedere cambiamenti nell’intero sistema?

Nel software, la portata di una modifica non è sempre determinata da ciò che appare sullo schermo.

Aggiungere un nuovo campo a un modulo, modificare lo stato di una richiesta o introdurre un ulteriore livello di approvazione possono sembrare interventi di poco conto. Ma in un sistema complesso, una funzionalità raramente esiste in modo isolato. Può essere collegata ai dati, alle regole dei processi, agli utenti, alle API, alla reportistica e ad altri sistemi.

Per questo, una delle prime domande da porsi nello sviluppo software non è semplicemente “Cosa deve cambiare?”, ma anche “Cos’altro sarà interessato da questa modifica?”

Ciò che vede l’utente è solo una parte della funzionalità

Prendiamo un esempio semplice: una piattaforma dispone di un processo di approvazione e deve essere aggiunto un nuovo livello di autorizzazione.

Nell’interfaccia, la modifica potrebbe tradursi semplicemente in un nuovo pulsante, un nuovo stato o un passaggio aggiuntivo. All’interno del sistema, però, è necessario stabilire chi è autorizzato a eseguire quell’azione, in quale fase è consentita, cosa accade allo stato del processo, quali informazioni vengono registrate nello storico delle attività e quali processi vengono attivati successivamente.

Se le stesse informazioni vengono utilizzate anche da altri sistemi, l’impatto può estendersi ulteriormente. Un’API potrebbe dover trasmettere il nuovo stato, un report deve essere in grado di interpretarlo correttamente e un sistema integrato deve sapere come gestirlo.

Quindi, un singolo nuovo elemento sullo schermo può corrispondere a diverse modifiche all’interno dell’architettura del sistema.

Il software funziona attraverso le dipendenze

I sistemi moderni sono costituiti da componenti che comunicano continuamente tra loro.

Un modulo può utilizzare dati creati da un altro. Un’API può trasmettere quei dati a un’altra piattaforma. Un report può basarsi sulla stessa struttura dei dati, mentre un altro processo può essere avviato automaticamente quando le informazioni cambiano.

Sono proprio queste connessioni a permettere al sistema di funzionare come un insieme coerente. Ma significano anche che l’impatto di una modifica deve essere valutato oltre il componente da cui ha origine.

Per questo, lo sviluppo non termina con l’implementazione di un requisito. È necessario comprendere anche la catena di dipendenze interessata da quel requisito.

Una modifica ai dati può propagarsi in tutto il sistema

I dati ne sono un chiaro esempio.

Se un sistema inizia a memorizzare una nuova informazione, non basta creare uno spazio in cui archiviarla. È necessario stabilire chi la crea, chi può modificarla, dove viene utilizzata, se deve essere trasmessa ad altri sistemi e come verrà visualizzata nei report o nei documenti.

Anche modificare il significato di un campo esistente può avere conseguenze. Altri componenti potrebbero essere stati progettati sulla base del modo in cui quell’informazione veniva interpretata in precedenza.

Per questo, nei sistemi complessi, modificare il software significa anche gestire le relazioni tra i suoi diversi componenti.

Le integrazioni estendono l’impatto oltre l’applicazione stessa

Questo aspetto diventa ancora più importante quando il software fa parte di un ecosistema più ampio.

Un sistema può scambiare informazioni con piattaforme finanziarie, sistemi di gestione documentale, servizi di identificazione, altre applicazioni o piattaforme di terze parti.

In questo caso, una modifica interna deve essere valutata anche dal punto di vista delle integrazioni. Una nuova struttura dei dati, una regola diversa o un nuovo stato possono richiedere adeguamenti anche nel modo in cui i sistemi comunicano tra loro.

Più un sistema è interconnesso, più diventa importante comprendere l’impatto complessivo di una modifica prima di implementarla.

Il lavoro più importante spesso inizia prima di modificare il codice

Per questo, un nuovo requisito non dovrebbe essere tradotto immediatamente in codice.

Prima dell’implementazione è importante comprendere dove interviene la modifica, quali componenti coinvolge, quali dati sono interessati, quali integrazioni dipendono da essa e se comporta conseguenze per altre parti del sistema.

Questa analisi è particolarmente importante per le piattaforme che si sono evolute nel tempo e nelle quali funzionalità, dati e integrazioni sono strettamente interconnessi.

In ALSoft, lo sviluppo dei sistemi viene affrontato proprio da questa prospettiva: una modifica non viene valutata soltanto come una singola funzionalità, ma come parte dell’architettura e dell’ecosistema in cui dovrà operare.

Come spiega Ermal Beqiri, fondatore di ALSoft:

«Nel software, una modifica non esiste soltanto nel punto in cui la vediamo. Diventa parte delle connessioni, dei dati e dei processi che tengono insieme il sistema. Comprendere queste relazioni prima di modificare il codice è importante quanto l’implementazione stessa.»

Il software è in continua evoluzione. Vengono introdotte nuove funzionalità, i processi cambiano e i sistemi si collegano a nuove tecnologie.

Per questo, la capacità di sviluppare un sistema non consiste semplicemente nell’aggiungere nuove funzionalità. Consiste anche nel comprendere come ogni modifica entra a far parte del sistema già esistente.