L’INCIDENTE DELLA FUNIVIA DI STRESA

E di come la sicurezza deve passare attraverso processi precisi e invalicabili

L’incredulità, gli occhi sbarrati di fronte alle prime notizie.
I brividi veri, quelli che ti scuotono fin dentro le ossa, quando ti rendi conto che potrebbe non essere stata una tragedia imprevedibile, ma c’è il tragico sospetto che sia stata frutto di decisioni od omissioni umane. 

Ero indeciso se scrivere queste parole. 

Non sono un esperto di funivie, non voglio sputare sentenze già troppo proclamate da ogni dove. 

Non voglio condannare e puntare il dito, non spetta a me. 

Vorrei solo analizzare le possibili soluzioni in termini di procedure.

Non quelle “a caldo”. Quelle saranno una danza di controlli a tappeto. 

Abbiamo oltre 1477 impianti a fune in Italia.

In quanti altri luoghi potrebbe ancora accadere?


Quanti altri boati immensi e innaturali potrebbero interrompere la quiete di quei paesi? 

Si susseguiranno verifiche, analisi, manutenzioni straordinarie. 

Se qualcun altro (e mi auguro proprio di no) aveva avuto la malaugurata idea di omettere dei controlli di sicurezza del genere, si sarà spaventato a morte pensando alle ben più gravi conseguenza a cui sarebbe andato incontro. 

Quindi, come ti dicevo, non importa molto la soluzione “a caldo”, ma quella a freddo, quando si saranno calmate le acque. 

Quando il boato assordante avrà finito di riecheggiare nelle nostre orecchie e ci sarà un altro problema all’ordine del giorno. 

Le soluzioni a lungo termine: quelle che davvero possono evitare le disgrazie

Facciamo una piccola premessa. 

Com’è fatta una funivia?


La faccio semplice, semplicissima, senza usare termini eccessivamente tecnici.
C’è un cavo grande come un braccio, il cavo PORTANTE.

Quello non si romperà “mai”, perché è progettato per resistere a forze molto superiori e viene controllato periodicamente. 

Quel cavo rimane fisso, con la funivia letteralmente appesa. 

E infatti non si è rotto quello. 

Poi ci sono i cavi TRAENTI

Sono quelli più sottili che si vedono di fianco. Tirano su e giù la funivia, attaccati ai motori veri e propri. Se quei cavi si rompono è un potenziale pericolo, perché la funivia potrebbe cominciare a scorrere sul cavo portante (ed è quello che è presumibilmente è successo a Stresa). 

Per evitare questo scenario c’è il FRENO

Ganasce che si agganciano con forza al cavo traente quando la funivia è ferma alle stazioni e che vengono rilasciate quando si deve muovere. 

Freno che in caso di pericolo diventa protagonista. 

In caso di brusche accelerazioni, calo di tensione, interruzione della corrente elettrica, guasti… diventa un FRENO DI EMERGENZA che blocca immediatamente la cabina, scongiurando la tragedia. 

Durante le operazioni di manutenzione però il freno potrebbe dare fastidio. Per questo c’è una FORCHETTA che tiene aperte le ganasce. 

SOLO CON LE CABINE VUOTE
SOLO PER IL TEMPO NECESSARIO per fare i controlli.

Solo-con-le-cabine-vuote.

Queste cinque parole mi rimbombano in testa e sono come cinque pugni in faccia. Fanno un male cane. 

A Stresa questa forchetta si sospetta che sia stata lasciata inserita, tenendo aperte le ganasce e impedendo il funzionamento del freno di emergenza, per evitare lavori di manutenzione e tenere fermo l’impianto.
Se questo è vero, da chi è stato fatto e perché, lo determineranno le doverose e minuziose indagini, ma per quello che ho da dire io in questo momento, è sufficiente questa ipotesi.  

Però… non è questo TUTTO il problema, c’è dell’altro. 

Poi, sembra sempre al momento come ipotesi credibile, che la reale causa scatenante è stata la rottura del cavo traente (che andrà comunque indagata perché un cavo non si deve rompere così), ma da sola non avrebbe causato nulla se non l’intervento del freno di emergenza. 

Ed è peggio. 

IL VERO PROBLEMA: la soluzione “a freddo”

Prima di tutto, sarà che sono abituato a pensar male per via del mio lavoro, ma la vera domanda che si fa anche un non addetto ai lavori è:

Quante altre funivie, in Italia e nel Mondo, hanno funzionato per anni con la “forchetta” inserita? 

Quante altre stragi sono state evitate per miracolo? 

E quante altre stragi potrebbero accadere se non si fa nulla? 


Questi pensieri, come ti dicevo, porteranno ad una soluzione “a caldo” che tappezzerà di controlli e verifiche la maggior parte degli impianti e che “metterà la strizza” a chi poteva avere avuto la stessa idea di queste persone.

Ma purtroppo queste sono le classiche lacrime del coccodrillo.

Quel sentimento forte, pesante come un macigno, che porta a voler spaccare tutto e agire immediatamente per impedire che una cosa così orribile possa ricapitare. 

Poi però passa il tempo, quel tempo che ha il potere di sfumare i contorni, di lenire le ferite. Quel tempo che ti permette di sopravvivere. 

Purtroppo è lo stesso tempo che permette che queste disgrazie ricapitino. Magari non nello stesso modo. 

Ma permettere che ricapitino. 

E chiunque abbia un’attività, un’azienda ha il dovere, verso se stesso prima di tutto, e poi verso i suoi dipendenti e clienti, di fare il possibile per limitare le probabilità che accadano questi errori.


PREVENIRE QUESTI ERRORI NEL FUTURO

L’errore umano può capitare. 

Gli esseri umani prima o poi sbagliano, questo è scontato nell’ambito della Safety: ci sono tabelle per ogni attività umana di un pilota, macchinista, che prevedono esattamente ogni quante ore una persona ignorerà un cicalino, una spia rossa, un allarme. 

È matematico, probabilistico: anche involontariamente, un uomo sbaglia. 

Il problema è quando non si tratta di errore ma di scelta consapevole

In questo caso sembra che non ci sia una soluzione. 

C’è lo sdegno, la vergogna, la difficoltà nel capire le dinamiche che hanno spinto ad un gesto così irresponsabile. 

Ma non è vero che non esiste una soluzione. 

Ce ne sono addirittura due. 



LA SOLUZIONE TECNOLOGICA 

In termini tecnici, una funivia dove è installata questa “FORCHETTA” è un 

sistema DEGRADATO

le sue funzionalità di sicurezza non sono presenti o comunque non sono garantite a livello di efficacia, per cui il sistema è pericoloso.
Siccome in caso di una funivia si tratta ancora di sistemi elettromeccanici, viene considerata un “Sistema Semplice”, per il quale si può raggiungere quella che è chiamata Sicurezza di Prodotto o PRODUCT ASSURANCE

Tramite analisi, progettazioni, simulazioni si riesce a rendere il sistema, se non matematicamente, almeno probabilisticamente sicuro. 

Gli incidenti nei sistemi elettromeccanici sono molto rari e il più delle volte causati dagli errori umani di cui abbiamo parlato. 

Posso immaginare quindi che la prima soluzione sarà di tipo tecnologico e meccanico. 

Verrà proprio impedito l’utilizzo di questa famigerata “FORCHETTA”, oppure verrà trovato un altro sistema per far viaggiare la funivia solo con cabine vuote in caso di manutenzione

Oppure dovrà essere modificato il sistema di blocco delle ganasce: facendo come succede in ambito avionico o in altri sistemi, quando questa forchetta è inserita (SE verrà mantenuta nella forma attuale), ci dovrà essere un segnale sonoro, visivo, meccanico che lo evidenzi in maniera inequivocabile, a prova di incapace. 

Hai presente le famose strisce rosse “REMOVE BEFORE FLIGHT” appese fuori da un aereo prima del decollo, da rimuovere appunto prima del volo?

Ecco, quello è il concetto. 

Potrebbe esserci un suono forte e inequivocabile causato dalla presenza della forchetta, oppure andrà fissata ad un grosso cartello o un altro dispositivo rosso, ingombrante e impossibile da ignorare. 

Ci potrebbe essere un sistema di blocco delle porte per evitare che salgano passeggeri. 

In poche parole: 


il sistema degradato deve essere segnalato o reso impossibile da usare, volenti o nolenti

LA SOLUZIONE SOFTWARE

Nel mondo dei sistemi basati su Firmware o Software Embedded, sempre più presenti nelle nostre vite, questo non basta!

Nel campo del codice, che oramai pervade ogni ambito, compreso quello delle funivie immagino così come tutti i sistemi elettromeccanici, purtroppo questo non è sufficiente. La soluzione del “Remove before flight” non è applicabile agli infiniti guasti che possono capitare a un’applicazione con una componente informatica. 

È complessa e con troppi livelli di profondità.
 

Milioni e milioni di righe di codice. 

Applicazioni e programmi che interagiscono tra loro. 

Le variabili da controllare sarebbero quasi infinite e questo le rende davvero difficili da gestire e dominare. 

Ancora peggio se, come purtroppo nel caso della funivia, si travalica il confine dell’errore umano. 

E si precipita nell’inferno della scelta consapevole. 

Tutto si può manomettere se c’è il dolo, l’intenzione pianificata di compiere un gesto preciso. 

Aspetta. So cosa stai pensando. 

Mi hai fatto leggere tutto questo articolo, arrivare fin qua… per dirmi che non esiste una soluzione efficace??” 

La soluzione esiste, non preoccuparti.



LA SICUREZZA DI PROCESSO 

Dopo le soluzioni “a caldo” di cui abbiamo parlato, pian piano si tornerà alla normalità. 

Ma per non rendere inutile tutto questo dolore bisognerebbe intervenire in maniera definitiva, agendo sul PROCESSO

Una cosa del genere non deve accadere perché a bloccarla ci devono essere una serie di impedimenti, diciamo burocratici per intenderci, per evitare che si ripeta in futuro. 

Più il sistema è complesso, più è all’avanguardia e implica quindi la presenza di un software, più la probabilità dell’errore diventa una scheggia impazzita e incontrollabile. 

I sistemi e le procedure che la gestiscono non possono essere gli stessi che a fatica tengono a bada i sistemi elettromeccanici. 

Per questo motivo, bisogna passare dal concetto di Sicurezza di Prodotto a quello di Sicurezza di Processo, in inglese PROCESS ASSURANCE.

 I concetti di base sono pochi e fondamentali: 

1) Controlli incrociati

La regola è molto semplice: uno fa, un altro controlla. 

Il famoso concetto che quattro occhi vedono meglio di due

Con un continuo controllo incrociato, in cui tutti hanno le stesse responsabilità, le probabilità di errore e di sabotaggio, si riducono notevolmente. 

In ambito avionico, si fa da sempre così ed è anche per quello che ci sono due piloti: per controllarsi a vicenda. 

2) Checklist

Ognuno di noi ha la sua esperienza, le sue conoscenze, le sue idee. 

Come si fanno i controlli, cosa si controlla e in quale ordine? 

Ognuno di noi farebbe controlli diversi. 

Da qui nasce la necessità di un deus ex machina che porti alla soluzione predefinita e ottimale. 

Per cui ecco le checklist: liste di controlli da fare e da spuntare, precise, ingegnerizzate, uguali per tutti, in tutto il mondo. 

A prova di errore, a prova di distrazione e stress, a prova di imbecille. L’unico modo per essere sicuri che i controlli vengano fatti, sempre nello stesso modo, da chiunque. 

Rimanendo sempre nell’ambito delle strette procedure che regolamentano gli strumenti degli aerei, ci sono checklist ben precise da seguire per ogni fase del volo (e prima di iniziare il volo). Ci sono lunghe check-list (così lunghe da essere veri e propri quaderni) solo per le operazioni anormali, ovvero come gestire situazioni di emergenza. 

È tutto prestabilito e ben poco è lasciato alla volontà del pilota. 

3) Verifiche indipendenti

L’ultimo passaggio è quello di Enti di Verifica esterni, autonomi, che facciano controlli casuali, a campione, improvvisi. 

Controlli non solo e non tanto tecnici, ma appunto di processo
Verifiche che siano state seguite le procedure, documentate le ispezioni, utilizzate le checklist, svolte le verifiche incrociate, firmati i verbali.

LA PROCESS ASSURANCE APPLICATA AL SOFTWARE

Questa strada ci rende più confidenti anche per il SOFTWARE, visto che tutte queste tecniche sono esattamente quelle che si usano per tutto quello che riguarda il SAFETY-CRITICAL (quindi come in questi casi dove è a rischio la vita delle persone), così come nei sistemi BUSINESS-CRITICAL dove i guasti possono provocare rallentamenti, disagi, perdita di dati ed economiche ma non mettono a rischio altri esseri umani.

Aumenteranno i controlli periodici, le ispezioni di organi ed enti indipendenti, le verifiche incrociate di personale esterno, gli organi di controllo, i bollini, i sigilli, le procedure ecc. rendendo di fatto molto difficile che si ripetano avvenimenti del genere. 

Questa è la vera, unica strada che l’aumento della complessità dei sistemi, soprattutto quelli moderni basati sul Software rende necessario: non è più sufficiente la striscia rossa “REMOVE BEFORE FLIGHT“, bisogna accompagnare la inesorabile conversione dei sistemi elettromeccanici in sistemi automatizzati e robotizzati, pieni di software.

Anche nella tua attività, nella tua azienda, puoi proteggerti da danni sia di business che di sicurezza. 

I secondi sono terribili e ti distruggono anche a livello personale e umano. 

Ma i primi non sono meno importanti.
Se il tuo prodotto o servizio viene bloccato da un problema al software come lo risolvi?

Non si tratta della vite o del pezzo di macchinario che puoi trovare e sostituire.
Il software è impalpabile, sfugge dal tuo controllo ed è molto complesso riconoscere e risolvere una sua anomalia.

Può causarti un danno d’immagine.
Può bloccare per giorni la tua produzione con danni economici che ti lascio solo immaginare…

Ma la strada del software può essere regolamentata e resa sicura, con processi determinati e precisi.

Quella che io chiamo la strada “dall’acciaio al bit“, tramite la lunga, faticosa PROCESS ASSURANCE

Prima di arrivare alla tanto chiacchierata ma ancora lontana Intelligenza Artificiale, Robot ecc., un sano e robusto processo, dei controlli periodici rigorosi, degli audit indipendenti e improvvisi sono e saranno per lungo tempo gli unici rimedi per evitare guai di questo genere, e questo vale per qualunque sistema o dispositivo, sia basato sul vecchio “acciaio”, che quelli nuovi e moderni oramai pieni di linee di codice Software. 

Per il disastro di Stresa io, come anche tu, non posso fare nulla. 

Possiamo però fare qualcosa per la tua attività, per prevenire qualsiasi tipo, più o meno grave, di incidente di percorso.

Sticky

SOFTWARE SICURO: il libro!

Il nuovo libro di Massimo Bombino

Il primo libro che ti insegna a sviluppare

Software Affidabile ad Alta Qualità 

con l’esclusivo Metodo M.E.D.S.

Ciao, mi presento: sono Massimo Bombino, e mi occupo dello Sviluppo di Software ad Alta Qualità da 30 anni, in particolare mi sono dedicato negli ultimi 20 anni al Software soggetto alla Certificazione Safety-Critical per il Settore Avionico e Aerospaziale, il settore più rigido e impegnativo ma anche quello dove ho imparato di più in assoluto su come impostare un processo di sviluppo software che sia veramente affidabile.

Ho lavorato (e lavoro tuttora) con aziende del calibro di: Ferrari Automobili, AUDI TTTech, Boeing, Airbus, Leonardo Finmeccanica, Aermacchi, Agusta Westland, Nortrhop Grumman, Piaggio Aerospace, Thales Alenia Space, Honeywell, Telespazio, Ansaldo, Hitachi, Datalogic, AUTEC Safety, Electrolux, Transenterix, Boston Scientific, STIGA, Tecnodal, Brusa e tantissime altre, aiutandole a ottimizzare il loro Ciclo di Sviluppo Software, identificare prima gli errori tramite la Modellazione e la Simulazione, migliorare la Strategia di Test, raggiungere prima la Certificazione.

Nel corso degli anni, con i miei collaboratori ho sviluppato un metodo di lavoro molto sicuro, affidabile e veloce di scrivere il software, attigendo al meglio che offriva il panorama mondiale.

Ma mica è sempre andata così: quando ho iniziato a programmare, oramai a fine anni ’80, il mio entusiasmo iniziale da neo-programmatore si è subito scontrato con le difficoltà dello scrivere codice… bug, instabilità, problemi vari, clienti che si lamentavano… insomma altro che infinite possibilità e flessibilità, la programmazione software assomigliava sempre di più a UN INCUBO!

Dopo anni di ricerche, studi su come scrivere software migliore e notti insonni passati a sbattere la testa contro gli stessi problemi che affronti anche tu quotidianamente con lo sviluppo del software, ho finalmente trovato la strada del Software Sicuro ed Affidabile per definizione: la severissima CERTIFICAZIONE AVIONICA DO-178C.

Al costo della molta rigidità nello standard avionico, di severi standard e controlli rigorosi, di procedure lunghe e costose, finalmente però lo sviluppo software diventava una disciplina ingegneristica e ripetibile, l’ideale per produrre codice di qualità.

E così ho scoperto oramai quasi 20 anni fa come tutto il Software Safety-Critical (medicale, automotive, ferroviario ecc.) fa capo a standard simili alla DO-178C (come ISO-26262, IEC-62304, IEC-61508 ecc.), sempre però piuttosto rigidi e costosi.

Ma non era sufficiente: quando parlavo di queste cose con i colleghi, i clienti, gli imprenditori scuotevano la testa… mi dicevano:

“Massimo, io non faccio software per aerei, io faccio firmware per lavatrici, per citofoniper apparecchi industriali, per elettrodomestici,  app per telefonini… non devo lanciare missili nello spazio, il tuo approccio è TROPPO COSTOSO E COMPLICATO! Io devo consegnare al cliente settimana prossima… non tra 2 anni”

Da lì è nata la sfida: dovevo trovare il modo di svecchiare questo processo così farraginoso e rigido, dovevo snellire le procedure troppo burocratiche, ma sopratutto dovevo trovare il modo di applicare questo metodo, o meglio una sua versione più flessibile, anche al software di tutti i giorni, quello Business-Critical.

Provando e riprovando, ho attinto al meglio dello sviluppo Safety-Critical, andandolo a rendere più gestibile e più flessibile con l’altro standard dello sviluppo software moderno: AGILE. Da questo strano incrocio, è nato un metodo di lavoro assolutamente innovativo e vincente, unico nel suo genere, perché unisce il meglio dei due mondi: l’approccio M.E.D.S. (Method for Efficient Development of Software).

Esatto:

ho preso il meglio in termini di sicurezza, affidabilità e ingegnerizzazione della Certificazione Safety-Critical e il meglio in termini di flessibilità, velocità e adattabilità di AGILE e DevOps e li ho messi insieme nel Metodo M.E.D.S.

Ho quindi deciso di mettere nero su bianco la mia esperienza internazionale, fatta in decine e decine di progetto in tutto il mondo e di creare più che un libro, una vera e propria guida allo Sviluppo di Software Sicuro, dove concentrare tutte le Best Practise, le migliori tecniche e i miei peggiori errori da evitare a tutti i costi.

Con questa splendida introduzione del mio amico Vance Hilderman (Ceo AFunzion), “guru” della Certificazione Avionica, voglio farti capire come questo NON sia il classico libro di informatica o similari: 

“Ci sono buoni libri di software, che consentono al lettore di essere più intelligente dopo la lettura rispetto a prima. Ci sono grandi libri, che permettono al lettore di essere più intelligente, mentre insegnano simultaneamente le migliori strategie per colmare le lacune di conoscenza. Il libro di Massimo è un libro fantastico in quanto spiega sia il mondo del software critico, sia le intuizioni per risolvere molti aspetti legati alla qualità del codice, oggi sempre più importanti. Max ha fatto un lavoro magistrale nel rendere interessante e divertente un argomento normalmente complesso e noioso. Ci mostra in questo libro come capire meglio il regno dello sviluppo del software Safety- e Business-Critical e come applicare queste conoscenze nel mondo reale. Io e Massimo abbiamo entrambi commesso degli errori tecnici sostanziali nei nostri decenni combinati di sviluppo di software e sistemi critici per la sicurezza: con questo libro, tu puoi prevenire gli stessi errori e capire al meglio come evitare di aggiungerne di altri”

Infatti, ti posso dire che questo libro non è (solo) un libro tecnico, didascalico, solo per addetti ai lavori, nemmeno un libro teorico, astratto, basato su concetti inapplicabili o un libro generico, che parla di mille cose senza concludere niente.

E’ invece un libro concreto, basato sull’esperienza di quasi 30 anni di sviluppo di software altamente critico; pratico in quanto presenta in maniera semplice e comprensibile i concetti che devi cominciare a conoscere per far diventare il tuo sviluppo software efficiente e snello, focalizzato su un aspetto ben preciso:

trasformare lo sviluppo software

da spina nel fianco e tuo punto debole

A VANTAGGIO COMPETITIVO STRATEGICO

Vuoi sapere come ho fatto? Allora continua a leggere…

Scrivere software è come scrivere un romanzo di Harry Potter

HAI MAI CONSEGNATO UN TEMA, UN ARTICOLO, UN LIBRO SENZA RILEGGERLO?

    OPPURE LO HAI MAI MANDATO IN STAMPA COSI’ COM’ERA, SPERANDO CHE IL LETTORE O IL PROFESSORE TROVASSERO LORO I TUOI ERRORI ?

    SE LO RILEGGI: OGNI QUANTO LO FAI?

 

Tu normalmente quando scrivi cosa fai, aspetti di avere scritto 300 pagine per dare una rilettura? O 50? Ovviamente la risposta è uguale per tutti: NO.

Questo è un esempio che faccio spesso ai miei clienti più digiuni dell’importanza teorica e pratica dell’attività di test del software.

 

Scrivere un software è come scrivere un libro: soprattutto quando si tratta di rileggerlo

 

Prendiamo uno studente, un professionista di un altro settore, un giornalista, uno scrittore. Possiamo prendere noi stessi come esempio, perché nella vita a partire dai banchi di scuola in poi, qualcosa l’abbiamo scritta: quando rileggiamo quello che abbiamo scritto?

Read More

Una spia sul tuo laptop HP?

Recentemente è stato scoperto un software nascosto in grado di registrare ogni lettera digitata su un laptop HP. L’impatto è di vasta portata, con molti modelli attuali di laptop HP che sono affetti dal problema. In questo post analizzeremo prima il problema del key-logging, quindi discuteremo un metodo migliore per impedire che ciò accada in futuro.

Un ricercatore di sicurezza informatica Michael Myng ha trovato del codice di keylogging nei driver software preinstallati sui laptop HP per far funzionare la tastiera. Ha scoperto il codice keylogger durante l’ispezione del software Synaptics Touchpad, mentre cercava di capire come controllare la retroilluminazione della tastiera sul portatile HP. Mr Myng ha dichiarato: “Il keylogger era disabilitato di default, ma un utente malintenzionato con accesso al computer avrebbe potuto abilitare la registrazione di ciò che un utente stava digitando.”

Secondo HP, è stato originariamente integrato nel software Synaptics per aiutare a correggere gli errori. HP ha riconosciuto che questo software di debug potrebbe essere sfruttato per provocare una “perdita di riservatezza”, ma ha affermato che né Synaptics né HP hanno avuto accesso ai dati dei clienti a causa del difetto.

Includere in fase di sviluppo del software come il keylogging è una pratica comune e viene inizialmente creato per aiutare gli sviluppatori a eseguire il debug del software. Questo codice può anche essere chiamato “codice di debug”. Tuttavia, quando il codice viene inserito nel software di rilascio ed esiste un semplice meccanismo per attivarlo, diventa un potenziale rischio per la sicurezza. Il codice di debug, una volta scoperto, verrebbe normalmente registrato come CWE (Common Weakness Enumeration). CWE è un dizionario online universale di punti deboli che sono stati trovati nel software per computer. Il dizionario è gestito dalla MITRE Corporation e può essere consultato gratuitamente su base mondiale.

Tuttavia, a causa della possibilità che possa essere sfruttato sul campo da alcuni software dannosi, è più che probabile che sia registrato come CVE (vulnerabilità ed esposizioni comuni). CVE è un catalogo di minacce alla sicurezza conosciute. Il catalogo è sponsorizzato dal Department of Homeland Security degli Stati Uniti (DHS) e le minacce sono suddivise in due categorie: vulnerabilità ed esposizioni.

Read More

Conosci il tuo debito… tecnologico?

Il software è stato inizialmente visto come qualcosa che poteva essere scritto una volta e usato molte volte senza mai “rompersi”. Tuttavia, quell’illusione svanì quando iniziarono ad apparire problemi, in ultima analisi causati da uno sviluppo continuo senza i giusti processi di controllo della qualità. Ciò era in genere dovuto a pressioni aziendali incredibili per rilasciare nuovi prodotti e funzionalità in un tempo compresso per essere sul mercato.

Questi problemi hanno portato ad applicazioni software che trasportano un’enorme quantità di problemi che hanno un nome ben preciso:

DEBITO TECNOLOGICO

Una metafora dei difetti latenti introdotti durante l’architettura, la progettazione o lo sviluppo del sistema. La difettosità accumulata quando le organizzazioni adottano queste scorciatoie di progettazione e test, al fine di raggiungere gli obiettivi a breve termine, alla fine rende il software difficile da mantenere. Con l’aumento del debito tecnologico, gli sviluppatori dedicano la maggior parte del loro tempo a correggere bug e a lottare con codice fragile, invece di concentrarsi sul core business e creare nuove funzionalità.

Molte organizzazioni ora stanno scoprendo che il software legacy ha in genere una diminuzione della durata della vita utile; dopo averlo creato e rilasciato, sono costretti a decidere se buttarlo via e ricominciare da zero, o cercare di recuperarlo. Nella maggior parte dei casi, è stato fatto un notevole investimento finanziario nella base di codice, quindi c’è una tremenda pressione per riutilizzarlo. La chiave per ridurre il debito tecnologico consiste nel rifattorizzare i componenti (il processo di ristrutturazione dei componenti di un’applicazione senza modificarne il comportamento esterno) nel tempo, ma gli sviluppatori sono spesso riluttanti a farlo per paura di corrompere le funzionalità esistenti. Uno dei maggiori ostacoli al refactoring è la mancanza di test che caratterizzano il comportamento esistente di un componente.

Questo è un problema crescente in quanto vi sono molte applicazioni distribuite basate su basi di codice legacy che non hanno i testcase necessari. Questo è aggravato quando il codice legacy viene distribuito su una nuova piattaforma o prodotto, poiché la mancanza di artefatti di test significa che il debito tecnologico continua a crescere senza possibilità di “ripagarlo”. C’è un enorme gap di qualità che deve essere affrontato, ma molte aziende non sanno da dove iniziare o non hanno le risorse necessarie per affrontare il problema.

Read More

5° Comandamento Software: NON UCCIDERE

Il software è uno dei prodotti più complessi mai prodotti dall’uomo, senza paragoni. Non esiste prodotto letterario, programma scientifico, opera architettonica che possa eguagliare il numero di ore/uomo o anni/uomo necessari a produrre un software di grande complessità come quello che equipaggia un moderno aereo, un’automobile di ultima generazione, il computer o smartphone che state utilizzando, un social come Facebook.

Ed il software è talmente complesso che spesso sbaglia… anzi, uccide.

 

Il software uccide le persone, brucia capitali enormi, fa saltare in aria le aziende, crea irreparabili danni di immagine

 

Nel 1982, si sospetta che la CIA abbia volutamente introdotto un bug (errore software) all’interno del codice di controllo della condotta di gas transiberiana in Russia. Per motivi di contro-spionaggio, gli USA hanno deciso di far esplodere tale condotta una volta operativa con il risultato di provocare la più grande esplosione non-nucleare della storia.

Read More

La tua azienda sta producendo pessimo software, bruciando prezioso budget in una spirale che presto ti manderà gambe all’aria. Te ne sei già accorto? E cosa stai facendo per evitarlo?
Tech Nerd theme designed by Siteturner