Aggiornamento 2023

Questo articolo è stato originariamente scritto alla fine del 2018. Ora, nel 2023, vengono riportate ulteriori informazioni.    Aggiornamento di aprile 2023 su Computer Weekly

Ciò che sappiamo ora è che c'erano "alcuni problemi", ovvero bug che colpivano diversi gruppi di client in modi diversi. Ci sono voluti almeno 7 mesi per risolverli. Possiamo solo stimare il numero totale di bug, ma è probabile che sia compreso tra 4 e 140. Lo sappiamo perché sono stati segnalati almeno 4 scenari di errore e il numero più probabile di bug che possono essere riparati in un sistema di produzione ad uso intenso è circa 1 al giorno, indipendentemente dalle dimensioni del team.

Costo della valutazione della qualità

A TSB è costato 32,7 milioni di sterline di risarcimento ai clienti, più una multa di 18,9 milioni di sterline e possiamo stimare uno sforzo tecnico di circa 3,2 milioni di sterline e un ulteriore impatto sul personale del servizio clienti di circa 52 milioni di sterline (consentire 1 chiamata a £ 10 per cliente). Poi c’è il costo opportunità di dover risolvere questo problema piuttosto che far avanzare la banca. E alla fine la banca avrà perso alcuni clienti per questo.

Il costo totale stimato sembra superare i 100 milioni di sterline. Il che ci dà un costo per difetto di circa 1 milione di sterline per difetto non scoperto prima della messa in funzione.

Come potrebbe essere evitato?

Conoscere il potenziale di difetto di un'attività software può informarti su quanti difetti devi trovare prima di essere pronto per la messa in funzione. È prevedibile. Utilizzando varie tecniche che ruotano attorno alla conoscenza delle dimensioni funzionali del software, dei potenziali difetti, delle aree a rischio di difetti, dei tassi di scoperta dei difetti, della copertura dei test e altro ancora, possiamo capire quali tipi di test saranno necessari e quanti test sono sufficienti per ottenere risultati soddisfacenti. qualità. Il punto è che quella terribile situazione era prevedibile ed evitabile. È interessante anche guardare la carriera di Carles Abarco su LinkedIn, da nessuna parte compare la parola qualità.

Cos’è il controllo adeguato nel 2023

Possiamo solo indovinare dalle conversazioni che Potrebbe hanno avuto luogo:

Esecutivo: “Hai fatto abbastanza test?”

Tecnologia: “Sì, ecco le centinaia di test che abbiamo fatto e tutti superati”.

Esecutivo: "Bene, quindi sei fiducioso, va bene andare in diretta?"

Tecnologia: "Sicuro."

Il fallimento era prevedibile ed evitabile. Probabilmente ci sarebbero voluti solo un paio di mesi per trovare e correggere quei bug prima della migrazione, senza dubbio tutti vorrebbero aver trascorso quei due mesi a risolvere quei problemi. Mi chiedo quali misure TSB e Sabadell si stanno adoperando adesso per garantire che questo scenario non si ripeta?

Colin Hammond, aprile 2023

La notizia che TSB mostra transazioni errate nei conti delle persone è la prova di un progetto software andato storto a causa del lavoro di scarsa qualità. Perché accade questo e come si sarebbe potuto evitare? La causa principale potrebbe derivare da una serie di possibilità; in questo articolo esplorerò alcune delle più probabili e le lezioni che possiamo imparare da esse.

Sistemi legacy sotto pressione

Al centro della maggior parte delle banche e dei grandi istituti finanziari c’è un software che è stato originariamente scritto molto tempo fa e che si è dimostrato molto affidabile. Chiamiamo questi sistemi legacy e poiché richiediamo modi diversi di accedere ai nostri dati bancari, il codice sottostante di questi sistemi legacy si ritrova a funzionare in modi che gli sviluppatori originali non avrebbero mai immaginato o previsto, questo può portare a bug rari.

Mantenimento delle tecnologie legacy

La maggior parte di questi vecchi sistemi sono scritti con vecchie tecnologie come un linguaggio chiamato COBOL. La maggior parte degli sviluppatori COBOL sono ormai in pensione e sono pochissimi i giovani entusiasti di imparare lingue così morte. Di conseguenza vi è una carenza di sviluppatori altamente qualificati per questi vecchi sistemi.

Il rischio porta all’astrazione

La migrazione dei sistemi legacy alle tecnologie più recenti è difficile e rischiosa. Possono volerci anni per pianificare e implementare. La sostituzione di un sistema centrale può essere così potenzialmente distruttiva che il management evita del tutto di farlo. Una tattica per consentire alle banche di andare avanti offrendo nuove funzioni agli utenti è quella di avvolgere questi vecchi sistemi utilizzando una tecnica chiamata Astrazione. Sono trattati come una “scatola nera” e non dobbiamo preoccuparci di come funzionano, dobbiamo solo avere fiducia nei loro input e output. Questa tecnica posticipa l'eventuale necessità di sostituire questi sistemi.

Architettura e complessità

Man mano che vengono creati nuovi prodotti bancari, sempre più sistemi dipendenti “appendono” l’eredità creando un quadro sempre più complesso di come i dati si spostano tra questi sistemi. I sistemi troppo complessi possono essere la causa di molti bug. Una buona architettura IT aiuterà a combattere o contenere questa complessità e il rischio associato.

Codice evoluto

I sistemi che esistono da molto tempo sono stati spesso modificati da molti programmatori nel corso degli anni. A volte c'è poco passaggio di conoscenze da uno sviluppatore a quello successivo. Il nuovo arrivato non capisce cosa ha fatto l'ultimo ed è riluttante a cambiare il codice esistente, nel caso lo infrangesse. Quindi scrive invece un nuovo codice per affiancarlo al vecchio codice. Entrambi i set di codice probabilmente fanno la stessa cosa, ma cosa succede quando arriva lo sviluppatore successivo, non può essere sicuro su quale codice lavorare. Questo è uno dei modi in cui la complessità può accumularsi.

I soli test non sono sufficienti per garantire la qualità

Gli studi su migliaia di progetti IT ci forniscono la prova che i soli test non garantiscono che tutti i bug siano stati rilevati. Infatti, nella migliore delle ipotesi, i test raramente troveranno più di 85% di bug. I test devono essere integrati da altre forme di tecniche di miglioramento della qualità in grado di identificare potenziali bug anche prima di iniziare i test. Alcune delle più efficaci sono l'analisi statica e le revisioni formali che riguardano requisiti, architettura, progettazione e codice.

Prova che non faccia quello che non dovrebbe

Supponiamo che tu stia effettuando una transazione sulla tua app bancaria, la connessione viene persa e solo metà delle istruzioni vengono inviate alla banca. In che modo il sistema della banca gestisce metà di un'istruzione? Se quel sistema è collegato a un sistema legacy, in che modo il sistema legacy gestisce un'istruzione incompleta. Ogni volta che apportiamo una modifica al sistema, testiamo sempre che il nuovo sistema faccia quello che dovrebbe fare. Dobbiamo anche assicurarci che non faccia ciò che non dovrebbe, questo tipo di test tende a essere trascurato.

Orario compresso

Senza dubbio, il lavoro svolto da TSB per migrare i sistemi avrà subito test approfonditi. Con tutti questi progetti, tuttavia, il team avrà avuto una certa pressione temporale per completare il proprio lavoro entro una data particolare. Una tempistica compressa è una delle cause più comuni di fallimento dei progetti IT.

Abilità tecniche

La programmazione è un lavoro creativo, che richiede abilità ed esperienza. Ad esempio, esistono molti modi per codificare lo stesso risultato, un programmatore può ottenere un insieme di funzionalità in solo una o due righe, un altro potrebbe doverne scrivere cinquanta. Nel complesso, il codice più compatto/conciso tende ad essere di qualità superiore. Le abilità degli sviluppatori variano notevolmente, confronta un cantante che ha un'intonazione perfetta con un altro che non riesce nemmeno a portare una melodia, entrambi si definiscono "cantanti". Gli sviluppatori con scarsa competenza possono introdurre più bug che correzioni o funzionalità.

Pressione aziendale per nuovi requisiti

Il management è sempre sotto pressione per far crescere la propria attività e in alcuni casi può perdere di vista l'importanza di sistemi stabili e accurati quando è sotto pressione per fornire nuove funzionalità e capacità.

Bug non previsti, quindi il rischio aziendale non è stato compreso

Contrariamente a quanto molti credono, i bug nel software possono essere previsti e misurati. Utilizzando le metriche software standard è possibile sapere quanti bug sono rimasti in un sistema prima di andare in funzione. Se ai manager venisse detto quanti difetti ancora da individuare, potrebbero non approvare la decisione di andare in produzione. È deludente vedere che pochissime persone utilizzano questi parametri. Sono (come COBOL) fuori moda ma funzionano. Offrono una notevole certezza a un settore che si è innamorato del “fail fast” e della “implementazione rapida” rispetto a parametri comprovati.

Conclusione

Ci sono molte possibili ragioni per i recenti problemi di TSB e ne suggerisco alcune qui. La verità è che la sostituzione dei sistemi legacy è molto più di una semplice responsabilità dell'IT: in alcuni casi è una questione che riguarda l'intera sopravvivenza dell'azienda. I clienti bancari potrebbero essere tolleranti se la loro app bancaria non è disponibile per alcune ore, ma non accetteranno saldi errati o transazioni gravemente ritardate. Ciò mina la fiducia e, senza fiducia, i clienti bancari andranno altrove. Colin Hammond è un consulente per la garanzia dei progetti IT e autore di ScopeMaster, uno strumento per dare certezza ai progetti IT.