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

Sicurezza di prodotto o di processo?

Se passi davanti a un negozio IKEA, può capitare di trovare questo strano dispositivo:


 

È una scatola di plexiglas trasparente, contenente una poltrona IKEA, uno strano braccio robotico con due grandi pistoni che spingono la sedia e un contatore. È una specie di esperimento di simulazione di una persona di 80 kg. seduto e in piedi, ripetuto per migliaia e migliaia di volte.

Probabilmente hai guardato il bancone, hai visto un numero come 999.999-1.000.000- … e hai fatto un po’ di matematica mentale

“Probabilmente io e la mia famiglia potremmo sederci e alzarci in media 10 volte al giorno, 3.650 totali all’anno … quindi questo la sedia durerà almeno 300 anni “

E con la giusta fiducia nella sua robustezza, hai deciso di comprarla.

Ora pensiamo a un software critico per la sicurezza: ti potrebbe essere richiesto di certificare secondo il severo standard DO-178C, fino al livello A. Bene, guardando questa o altre normative di sicurezza correlate, potresti trovare che associato al livello A, hai una probabilità di errore 10E-9 ore di volo. Ok, ancora matematica… significa:

1 miliardo di ore senza problemi, o meglio 11.574 anni

Undicimila anni! Sembra abbastanza buono, non è vero? Tranne il fatto che… per il software, in realtà non funziona così. Cosa significa veramente DAL-A? Letteralmente, significa Design Assurance Level: garanzia del DESIGN.

Ma la vera probabilità di un guasto del software è molto più alta … alcuni esperti dicono che la probabilità è 1 ovvero il 100%! Potresti essere abbastanza sicuro che il tuo software fallirà! Pensa al tuo sistema operativo desktop o mobile … puoi immaginare un’app per il tuo smartphone o computer che resista migliaia di anni senza crash o bug?

E pensi che il software avionico possa essere reso così solido per millenni? Possa davvero essere rilasciato fin dall’inizio totalmente senza bug?

NON E’ COSI’

ed ora ti spiego perché.

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

SOFTWARE DA INCUBO!

 

“Siamo in ritardo per colpa del software”

“Dovremmo adottare un nuovo processo di sviluppo ma non abbiamo il tempo”

“Un tool molto interessante ma non c’è budget, mi spiace”

“ Il nostro metodo di sviluppo software è molto artigianale”

“Non abbiamo tempo di testare perché dobbiamo uscire col prodotto”

“Il test è noioso e costoso, dobbiamo tagliare i tempi”

“Vogliamo stare concentrati sul nostro core-business”

“Dobbiamo richiamare 10.000 unità dal mercato per un problema”

“Alcune persone si sono ferite utilizzando il nostro dispositivo”

“I parenti dei nostri clienti vittime di incidenti con i nostri veicoli si sono organizzati in una class-action”

 

Se qualcuna di queste frasi ti è nota perché è girata nella tua azienda o in quella di un tuo concorrente, oppure se il solo sentirla ti fa venire un brivido freddo: allora questo blog è per te.

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