Un software da 500 milioni di dollari?

No, il titolo non è una provocazione ma un caso reale che ti spiegherò fra poco: tu pagheresti 


un aggiornamento software 500 milioni di dollari?

 
E che cosa dovrebbe mai combinare di buono (o di cattivo!) la nuova versione di un applicativo per costare così tanto?  Ma soprattutto, come si è arrivati in soli 30 minuti a un disastro del genere in un’azienda americana, Knight Capital, che è stata sull’orlo della bancarotta per questo motivo ed è stata costretta a reperire in poche ore ingenti risorse economiche, licenziare alcuni dipendenti e vendere degli edifici di proprietà a causa di questo tracollo finanziario provocato da un software?

Read More

Presentazione corso M.E.D.S.

Questo video servirà a presentare il nuovo corso M.E.D.S. sul metodo più innovativo e strategico mai visto in Italia nel campo del software critico:
Method for 
Efficient 
Development of 
Software

Presentato da Massimo Bombino, una delle autorità di riferimento del software Safety-Critical in Italia, e da Giuseppe Randazzo, esperto di sofware per la robotica, il webinar parlerà di questo nuovo metodo M.E.D.S. e di come si stia affermando, grazie anche al libro Software Sicuro, come  

l’unico modo di gestire un progetto software in maniera efficiente, sicura e soprattutto remunerativa   

Infatti, non sarà solamente un corso tecnico, anche se ovviamente verranno trattate alcune tematiche avanzate, ma si tratterà di un vero e proprio corso che si rivolge principalmente a MANAGER NEL MONDO DEL SOFTWARE: quindi a tutti coloro che gestiscono team (o intere aziende) dove il software giochi un ruolo fondamentale nel fornire le funzionalità del prodotto.


I 5 principi fondamentali del corso M.E.D.S:

  1. STRATEGIA
  2. ECONOMIA
  3. GESTIONE
  4. SUPPORTO
  5. PROCESSO

sono l’unico modo per tenere sotto controllo non solo gli aspetti tecnici (dove sicuramente sei già bravo, ma qualcosa da imparare c’è sempre anche e soprattutto dagli eccellenti co-docenti come appunto Giuseppe Randazzo e… un importantissimo ospite che verrà svelato nel webinar!), ma soprattutto aspetti di marketing specifico per il software, di posizionamento sul mercato, di costi e di ritorno dall’investimento, di gestione di team anche distribuiti geograficamente, della gestione dell’imprevistoe altre tematiche di sicuro mai affrontate in Italia, almeno non in uno stesso corso.


Tu pensa come potresti essere avanti rispetto alla concorrenza, applicando queste tecniche… che saranno poi ben esposte nel corso M.E.D.S. Milano (Autunno 2020).

Il videoPresentazione corso M.E.D.S.” è disponibile sul nostro canale YouTube:

I 10 peggiori errori nel software che devi assolutamente evitare

Qual è la classifica dei 10 peggiori errori nel software che potrebbero far saltare il tuo progetto o la tua azienda?

Ho commesso errori nella mia vita professionale, tanti, anche se fortunatamente non troppi: è la strada inevitabile degli innovatori, dei curiosi, di chi adotta tecnologie promettenti o al contrario è obbligato a utilizzare quelle vecchie per vincoli aziendali imposti. Ancora più spesso, mi sono trovato a gestire i problemi degli altri! Guai a ripetizione per scelte magari fatte da chi c’era prima di me, o gerarchicamente sopra di me, o che metteva i soldi ma non si rendeva conto di quello che erano le conseguenze di certe scelte.

Ma oltre agli effetti negativi, per i quali ho quasi sempre dovuto trovare personalmente delle soluzioni o comunque dei rimedi, ho passato anche tantissimo tempo a pensare a come evitare di farli in futuro e come evitare che li facessero i miei clienti e i miei collaboratori.

Così come ci sono tanti colleghi, clienti, partner strategici con cui mi confronto quotidianamente, che da sempre vista la mia passione e dedizione alla tecnologia, mi hanno riferito le loro “disgrazie” sulle quali siamo finiti a ragionare insieme, al lavoro ma spesso anche in orari improponibili a cena se non dopocena, passati a parlare di lavoro ed elaborare insieme una soluzione, un rimedio ma soprattutto il modo per scongiurare il loro ripetersi.

Da queste cattive esperienze e dall’enorme fatica fatta per comprenderle in profondità, ho imparato tanto: mi permetto di suggerirti quali sono i 10 peggiori errori, in modo che tu possa evitare le stesse conseguenze disastrose in futuro, e le migliori strategie per evitarli.

Read More

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

LA PRIMA AZIONE per mettere in sicurezza il tuo software

Se tu dovessi decidere di fare un primo passo, uno solo, per incominciare a mettere in sicurezza il tuo software, da cosa dovrebbe partire? Quale potrebbe essere la singola azione più redditizia da mettere in pratica immediatamente per avere dei risultati evidenti soprattutto nel medio e lungo periodo e consolidati che portino ad un evidente e misurabile miglioramento della qualità del codice prodotto?

Te lo racconto a partire da una storia vera che mi è successa tanti anni fa, all’inizio della mia carriera lavorativa, ma che somiglia a tantissime altre storie simili che sicuramente saranno successe a te e a tutti coloro che si occupano di software.

Stavo sviluppando un piccolo pezzo di programma per un cliente, che metteva in collegamento due tool diversi, un “bridge” diciamo. Rilasciata una prima versione del software, ho cominciato a ricevere da parte del cliente una serie di email che mi segnavano alcune anomalie. All’inizio analizzavo le segnalazioni ed apportavo prontamente delle correzioni. Benissimo, il codice comunque funzionava bene e faceva già da subito il suo “dovere”. Ma non bastava.

Le email hanno cominciato ad accavallarsi e a dimostrarsi strumento poco adatto a gestire la situazione: non era chiaro quali erano i problemi aperti e quelli risolti, in che versione erano stati risolti, per cui si è passati ad un sistema rudimentale di Bug Tracking, basato su Excel, su cui tornerò. Questo accorgimento ha migliorato molto la situazione, anche se non era finita così.

Si procedeva comunque abbastanza bene fino a quando ad un certo punto, si sono cominciate a creare delle situazioni non proprio piacevoli, anche se molto note: il cliente ha cominciato a lamentarsi sì di funzionalità non presenti o che non funzionavano poco, ma anche di aspetti tutto sommato estetici o del tutto secondari. Anche qua sembrava risolto, al momento.

Alla fine, sono fioccate richieste che seppur apparentemente logiche, del tipo: i file di log devono avere il formato YYYY_MM_DD_HH_SS.log invece che HH_SS_DD_MM_YYY.log e decine simili che erano sicuramente ragionevoli, ma che avevano in comune con tantissime altre una caratteristica:

NESSUNO LE AVEVA CONCORDATE PRIMA!

Stava succedendo una cosa MOLTO spiacevole: il cliente mi tempestava di richieste, diligentemente divise per priorità, catalogate e condivise in un sistema di tracciamento errori, ma la verità era una soltanto.

IL CLIENTE SE NE STAVA APPROFITTANDO CHIEDENDO FUNZIONALITÀ’ ED ASPETTI LOGICI ED ESTETICI CHE NON AVEVAMO STABILITO E CONCORDATO IN ALCUN MODO

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

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