Business- e Safety-Critical Software

Lezione ZERO!

E’ in corso la Lezione ZERO del mio nuovo Corso di (NON) Programmazione:    

l’unico corso che ti insegna DA ZERO i trabocchetti, i segreti, le migliori pratiche della Programmazione Embedded & IoT, per ambienti Business e Safety-Critical

Sei curioso? Partecipa GRATIS alla LEZIONE ZERO!

  Già, nulla di meglio che vedere con mano quelli che saranno:    

• la filosofia di base del corso, che lega come un fil-rouge tutto quello che faccio nella mia vita lavorativa
• i contenuti del corso, presentati in maniera approfondita
• le esercitazioni pratiche che gli studenti dovranno svolgere
• il caso di studio che ci accompagnerà durante tutto lo svolgimento del corso
• le abilità e le competenze che acquisirai con un programma del genere
• i primi concetti di programmazione che devi conoscere ancora prima di scrivere anche solo una riga di codice
• la sessione di Domande e Rispostein modo da toglierti ogni dubbio

Così capirai se il corso fa per te e per il tuo team (come spero), oppure se sei già un esperto di tutte queste tematiche per cui, fortunatamente, non ne hai bisogno.  

Quando? Oggi, Giovedì 9 Luglio ore 14

Esatto: tra poche ore,  un webinar in diretta accessibile non solo agli studenti già iscritti, ma a tutti quanti. 
Un po’ prima delle 14, collegati qui:

Corso di (NON) Programmazione: Lezione ZERO

Ci vediamo oggi alle 14!
Massimo

Prima volta che usi GoToMeeting? Fai un breve controllo se il tuo PC/Smartphone/Tablet è compatibile:   
https://link.gotomeeting.com/system-check

Ridicola, se ci ripensi, la sensazione che hai provato alla fine del tuo percorso scolastico, Maturità, Esame di Laurea o Dottorato che sia: quella di aver finito finalmente di studiare.

Non avevi coscienza, in quel preciso istante, del tuo futuro prossimo e degli anni a venire:

una quantità impressionante di ulteriori corsi di formazione, tecnici, professionali, di aggiornamento

Corsi che hai dovuto seguire per essere sempre informato sullo stato dell’arte della tecnologia, per poter accedere ad un certo ruolo, per ottenere una promozione, per avere i crediti necessari nella tua professione, il tutto più o meno volontariamente se non addirittura costretto dalla tua azienda.

Bene, ora fai mente locale e dimmi TRE CORSI TECNICI, SCIENTIFICI che ti sono serviti VERAMENTE nel tuo lavoro, per miglioralo drasticamente, per rivoluzionarlo o addirittura per cambiarlo del tutto. Che hanno stravolto seriamente la tua vita professionale. Che ti hanno aperto un mondo finora sconosciuto e che hai poi in seguito deciso di approfondire e far diventare tuo.

Fai molta fatica, vero? Sì, sei stato bombardato tuo malgrado come me da decenni di corsi professionali, tecnici, workshop, seminari, bla bla bla pallosissimi, nozionistici, pieni di un sacco di informazioni inutili da applicare nel breve termine, con il solo vantaggio che ti hanno permesso di staccare per qualche giorno, mettere l’auto-responder alla mail e spegnere il telefonino, solo per essere distratto per qualche ora dal tuo lavoro quotidiano, dal tuo capo, dai clienti rompiscatole.

Ma pochissimi, se ci sono stati, sono stati eventi di formazione che hanno rappresentato veramente una pietra miliare, uno spartiacque tra il prima e il dopo.

Esatto, il 99.99% (ad essere ottimisti) dei corsi in circolazione soffrono di 3 grandi classici difetti. Proviamo a vedere se sei d’accordo su questi, poi se mi segui ti faccio fare un ulteriore salto in avanti.

Read More

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 (PRIMAVERA 2021).

Il video “Presentazione corso M.E.D.S.” è disponibile sul nostro canale YouTube:

“A fool with a tool, is a more powerfool fool”

Oramai è sulla bocca di tutti: un secondo aereo 737 MAX della Boeing è caduto nel giro di pochi mesi in Etiopia, pochi mesi dopo quello di fine 2018 in Indonesia. A questo si è aggiunto poi un mancato incidente sullo stesso identico aereo etiope, il giorno prima, che è stato evitato per puro caso dall’intervento di pilota a riposo che si trovava per caso nello stesso aereo e che è corso in cabina per evitare una tragedia, fornendo una delle chiavi di volta per comprendere meglio le due tragedie.

Non è mia abitudine commentare incidenti appena avvenuti, perché le indagini per stabilirne le vere cause possono durare anche mesi: ma questa volta forse forse si sa già chi potrebbe essere il colpevole: infatti, in tutti gli incidenti sia quelli realmente accaduti che in quello mancato, si è evidenziato come i piloti stessero combattendo invano contro i sistemi a bordo del loro stesso aereo:  precisamente, lottavano contro un sistema “demoniaco” di stabilizzazione chiamato M.C.A.S., basato su un software di correzione delle manovre potenzialmente pericolose che paradossalmente ha contribuito a creare i presupposti delle due tragedie.

Bene, abbiamo finalmente il responsabile?

Il software ha veramente ammazzato centinaia di persone?

Gli aerei non sono più sicuri?

Forse, ma la realtà invece è molto diversa da quella che appare in prima istanza. E la lezione imparata oggi, può essere utile anche a te e alla tua azienda…

Seguimi in queste considerazioni in cui cercherò di non scendere troppo nel tecnico e vedrai che questa analisi ti sarà molto utile, qualunque tipo di software tu stia producendo.

Cosa è successo?

Allora, al di là del motivo originario per cui sia successo un fenomeno del genere, appare evidente dalle scatole nere e dall’episodio dell’incidente mancato che l’aereo sembrava essere completamente impazzito: dai cambi di quota repentini, dalle manovre effettuate dai piloti, dalle loro voci registrate nel cockpit sembrava proprio che l’avionica di bordo avesse deciso di puntare l’aereo con decisione verso terra, quasi a scansare un imminente pericolo.

Il problema è che questo pericolo non c’era e che puntare verso terra subito dopo il decollo, ancora a bassa quota e bassa velocità, è molto intuitivamente una cosa molto pericolosa… e se fatta in maniera repentina e più volte, può provocare una tale instabilità e perdita di quota da provocare i disastri poi avvenuti.

Ma perché quindi questo tipo specifico di aereo ogni tanto (troppo spesso!) impazzisce, fa quello che vuole, punta il muso verso terra ammazzando tutti? E perché i piloti sono impotenti in tutto questo?

Soprattutto: è vero che non potevano fare nulla per evitare il disastro? Qui ci sono molti, molti dubbi…

Aereo o bus?

Parte tutto da una famosa diatriba ben nota tra addetti ai lavori o appassionati di aerei: Boeing o Airbus?

Il motivo del contendere è un oggetto ben preciso: UN JOYSTICK.

Esatto: gli Airbus da molti anni non si guidano più con la classica cloche a due mani che tutti conoscono, ma con un joystick identico a quello dei videogiochi. Quando è stato introdotto il concetto di Fly-by-Wire, il controllo degli elementi di comando di un aereo tramite sistemi elettronico e non più solamente meccanico-idraulici, è stato un salto quantico, nella sensazione di guida di un aereo e nell’avionica in generale, con un sacco di critici e un crescente numero di appassionati, le cui opinioni ovviamente si ribaltano radicalmente nel momento in cui si parla del Boeing che invece ha una cloche di guida più tradizionale:

Ma anche l’avionica di un Airbus è molto diversa: per non farla troppo lunga e tecnica, esiste una cosa in tutti gli aerei chiamata “INVILUPPO”, che rappresenta una specie di cuscinetto di sicurezza intorno alla posizione dell’aereo, una zona di prudenza in cui il velivolo deve sempre trovarsi per essere in una condizione stabile senza rischi. Un insieme di dati complessi di velocità, inclinazione, accelerazione con dei limiti che non devono mai essere oltrepassati per non mettere in pericolo l’aereo stesso e il suo equipaggio.

Ecco, la grande differenza tra i due colossi dell’aria è che negli Airbus, l’avionica di bordo esercita un controllo molto forte  per assicurare che l’aereo si trovi sempre correttamente all’interno dell’inviluppo e che soprattutto evitare che il pilota faccia mai, neanche volontariamente, delle azioni o delle manovre pericolose, a meno di disabilitare volontariamente alcune funzionalità del cosiddetto “pilota automatico”.

Di fatto, l’aereo guida quasi sempre da solo, scegliendo in ogni condizione la manovra migliore per evitare (in teoria) qualunque tipo di problema. Questo fatto, secondo alcuni, rende i piloti di Airbus così abituati all’aereo che manovri quasi sempre da solo ed eviti autonomamente qualunque rischio, da diventare pigri e disimparare come si guida veramente un velivolo manualmente, tanto da essere chiamati “bus drivers”, guidatori di (Air)bus.

Un pilota Boeing invece, con la cloche tradizionale, prima di tutto ha una sensazione tattile e visiva di quello che sta facendo lui e il co-pilota, visto che le cloche si muovono insieme. Ma soprattutto, anche se alcuni sistemi elettronici di ausilio alla guida sono stati introdotti pure in questi aerei, può escludere istantaneamente il pilota automatico con una semplice pressione sui comandi più decisa del solito, e riprendere totale controllo dell’aereo. Questo significa ovviamente esserne anche capaci e infatti i piloti di Boeing normalmente vengono ritenuti più abili proprio a guidare l’aereo in maniera manuale e a “sentirne” il comportamento, visto che lo praticano molto più spesso, piuttosto che fidarsi e lasciarlo pilotare da solo.

In prima istanza, estremizzando verrebbe da dire che gli Airbus sono più sicuri perché automatici e i Boeing invece necessitano di piloti migliori… in maniera MOLTO superficiale, potremmo per un momento anche dire così.

Ok, ma… non è successo ESATTAMENTE il contrario? Non è stato un aereo Boeing a cadere e per colpa di un sistema automatico? Quindi il contrario di quello che uno si sarebbe aspettato, no?

Beh, ma è PROPRIO quello il problema…

Cos’è il M.C.A.S. e perché non è ancora il vero colpevole

Allora, il nuovo Boeing 737 MAX, come suggerisce il nome stesso, era la versione più grande dello stesso modello di aereo di grande successo e dalla grandissima affidabilità, dotato anche di più potenti.

Il problema è che la potenza dei motori, la loro posizione, i cambiamenti introdotti potevano creare delle situazioni di pericolo, di uscita dal famoso “inviluppo”, in particolari condizioni di volo a bassa velocità e angoli di volo elevati che potevano portare ad uno stallo del velivolo. Per evitare questo grave tipo di pericolo, la Boeing ha avuto la grandissima pensata (!!!) di introdurre un sistema anti-stallo elettronico chiamato M.C.A.S. (Maneuvering Characteristics Augmentation System), molto simile a quelli presenti negli aerei Airbus.

Lo scopo era preciso e anche lodevole, anche se diabolico nella sua attuazione: far volare senza pericolo il nuovo MAX ai piloti già addestrati con il vecchio 737 NG.

Sembra tutto ok, no? Un sistema per rendere i nuovi velivoli più sicuri… andando un po’ a inseguire Airbus nell’automatizzare i sistemi di volo e a ridurre il carico di lavoro e la richiesta di maggior abilità dei piloti.

Allora è vero che il software ha fallito? No: sono stati dei sensori.

La colpa è dei sensori… anzi no

Per funzionare, questo sistema M.C.A.S. ha bisogno, tra gli altri dati, dell’Angolo di Attacco (AoA) forniti da alcuni sensori… che detta in maniera molto semplice indicano l’inclinazione dell’aereo. Bene, sono stati questi dispositivi ad avere avuto un malfunzionamento e ad aver dato indicazioni del tutto errate che hanno fatto impazzire l’autopilota.

In poche parole, i sensori segnalavano che l’aereo si era impennato in maniera pericolosa… e cercavano di ributtare giù il muso. Peccato che non fosse vero, l’aereo stava volando dritto… e come in un vero incubo, il software di bordo continuava a far perdere quota all’aereo nonostante i ripetuti interventi del pilota per rialzarlo.

Vi immaginate che incubo? Siete alla guida di un aereo pieno di passeggeri che impazzisce e vuole precipitare verso terra… voi provate a raddrizzarlo per decine e decine di volte ma niente, punta inesorabile verso la morte.

Finalmente: colpa dei sensori? E no, c’è un motivo per il crash… e ancora una volta non sarà quello definitivo.

Un problema di soldi (o di progetto)

Questo sistema M.C.A.S.aveva in realtà a sua volta un meccanismo di diagnosi interna di tutte le sue componenti, inclusi questi sensori di angolo di attacco, chiamato DLC. Una volta che questo sistema avesse segnalato un problema, i piloti sapevano (in teoria…) che avrebbero dovuto disinserirlo (attenzione che torneremo su questo punto) e tornare a guidare in maniera manuale, come erano stati addestrati a fare.

Peccato che questo dispositivo fosse… opzionale e costoso, per cui alcune compagnie aeree più “povere”, non l’hanno acquistato. E guarda caso, sia gli aerei della flotta Indonesiana che di quella Etiope non erano dotati di questo sistema di diagnosi e di allarme, per cui i piloti si sono trovati in balia di un aereo che faceva di testa sua, inventandosi una situazione di pericolo che non c’era e anzi andandola a creare. Tutto questo per una questione di soldi.

Certo uno potrebbe dire: ma cavoli, in un sistema così delicato e potenzialmente salva-vita, non dovrebbe essere integrato di default un sistema di auto-diagnosi che vada a verificare che tutto funzioni correttamente, dai sensori agli attuatori, dai computer al display?

Per cui anche il costruttore ha le sue colpe… avrebbe dovuto rendere il nuovo sistema di guida automatico sicuro in tutte le situazioni, anche in quelle di guasto.

Facciamo il punto della situazione prima di annunciare chi è… il “maggiordomo”, il colpevole vero di questi tristissimi incidenti.

La catena di eventi scatenanti

Quindi, abbiamo questa catena di eventi che sembra piuttosto chiara:

• l’aereo 737 MAX è più grande e monta motori più veloci di quelli precedenti
• essendo più potente, potrebbe creare situazioni in cui l’impennata del muso provocherebbe situazioni di grave instabilità di volo (stallo)
• per evitare questo problema ed evitare stress (e nuovo addestramento) ai piloti, è stato introdotto un sistema anti-stallo chiamato M.C.A.S.
• i sensori dell’Angolo di Attacco (A.o.A.) erano guasti e fornendo informazioni inventate, facevano intervenire a sproposito il M.C.A.S. facendo precipitare l’aereo nonostante le correzioni disperate dei piloti
• esisteva un sistema di diagnostica di tali sensori che avrebbe avvertito i piloti di disinserire il M.C.A.S.  ma le compagnie aeree indonesiani ed etiope non l’hanno comprato perché troppo caro

Sembra tutto chiaro, ma io come in un giallo ho disseminato degli indizi per il colpevole finale, quello vero.

Infatti, se sei stato attento, ti sarà venuta in mente la domanda fatidica:

Perché i piloti non hanno disinserito il M.C.A.S.?

Eh già, questa è la VERA domanda. Quella fatidica.

La possibilità di disinserire quella trappola mortale c’era, ma i piloti non l’hanno utilizzata nei due voli fatidici. Mentre nel volo etiope del giorno precedente, un pilota a riposo tra i passeggeri ha capito cosa stava succedendo e si è precipitato in cabina per salvare piloti, aereo e passeggeri. Un eroe? No: semplicemente UN PILOTA INFORMATO E ADDESTRATO.

Infatti, i piloti di entrambi gli aerei precipitati, così come molti altri piloti Boeing in giro per il mondo, avevano uno o più di questi gravi problemi di addestramento:

• NON SAPEVANO CHE ERA STATO INTRODOTTO IL M.C.A.S.
• NON SAPEVANO COME FUNZIONAVA E QUANDO SCATTAVA
• NON NE CONOSCEVANO LE REAZIONI ANOMALE IN CASO DI GUASTO
• NON SAPEVANO NEANCHE COME DISINSERIRLO!!

Vabbè, dirai, cose da PAZZI!! Sembra una follia totale, un film horror, sapere che banalizzando,

bastava schiacciare un bottone, premere un pulsante per disinserire il software mortale M.C.A.S.

Brivido di terrore.

E veniamo all’ultimissima domanda: perché i piloti non sono stati addestrati??

La fretta di arrivare sul mercato

Esatto: è presto per la conferma definitiva, ma sembra che il mancato o scarso addestramento sia stata una strategia precisa per far diventare velocemente operativi i nuovi piloti sul mercato.

Infatti, alcune voci di CBS News raccontano che

ai piloti sono stati fatti soltanto 56 minuti di formazione su un iPAD per il nuovo 737 MAX

Allucinante.

Hanno preso un aereo sicuro, storicamente affidabile, dei piloti bravi e competenti, che sapevano pilotare in condizioni anche rischiose in modalità manuale… e gli hanno infilato dentro un nuovo sistema, un software, un “tool” che doveva rendere la loro vita più facile, ma li ha ammazzati perché non ne sapevano niente. Roba che mi provoca i brividi freddi solo a pensarci.

Ancora una volta, così come per il sistema di diagnosi DLC non acquistato, per risparmiare i costi… i tempi… per comprimere il famigerato TTM (Time to Market), il vero killer di queste due tragedie.

E tu? Lo sai benissimo, se hai letto altri articoli miei, che ti tirerò in mezzo con una bella “lezione” su quanto appreso oggi da applicare alla tua azienda.

La (mancanza di) cultura uccide

Pensaci un attimo, quante volte nella tua azienda, nel tuo team per problemi di budget e/o di tempo:

• hai introdotto dei cambiamenti in azienda senza informare tutti?
• hai acquistato un tool senza comprare il corso adeguato?
• hai cambiato delle procedure senza informare e formare tutte le persone coinvolte?
• hai magari migliorato dei processi ma senza coinvolgere chi ne era affetto?

Ecco: tutte queste volte, tu hai potenzialmente corso il rischio di:

• di AMMAZZARE I TUOI CLIENTI, se il tuo software è SAFETY-CRITICAL
• di FAR FALLIRE I TUOI CLIENTI (E TU CON LORO), se il tuo sistema è BUSINESS-CRITICAL

Conclusioni

Ti è piaciuto questo articolo? Scopri la mia newsletter gratuita dove periodicamente troverai:

• analisi dettagliate di incidenti critici (apparentemente) causati dal software
• strategie ottimali per produrre software Safety- e Business-Critical
• consigli su come adottare delle tecniche sicure ed efficaci nei tuoi progetti

Lascia la tua email per avere immediatamente accesso alla mia newsletter:

Se ci sei passato, saprai benissimo che la Certificazione Avionica Safety-Critical del Software ha una brutta fama… quella di letteralmente un bagno di sangue.

Sono tantissime le cose che devi fare di più rispetto a un normale progetto… vediamo alcune tanto per intenderci:

• Avere un processo formale, rigido e ben definito
• Rispettare formalmente tutte le fasi del ciclo di vita e le transizioni fra di esse
• Soddisfare tutti gli obiettivi richiesti tramite attività, documenti, evidenze, checklist
• Dotarsi dei migliori strumenti nonché di fornitori o sub-contractor adeguati

In poche parole… questo vuol dire solamente tre cose:

SOLDI, SOLDI e ancora SOLDI

E ovviamente tempi molto più lunghi, ritardi che si dilatano in maniera esponenziale così come i rischi di insuccesso e via discorrendo.

Esiste una via più rapida ed efficiente alla Certificazione Avionica?

E’ possibile riuscire ad essere più efficienti , senza sacrificare nessuno degli obiettivi Safety-Critical? Si possono accorciare i tempi, senza scordare nessuno degli obblighi dati dagli standard? Come si possono contenere i costi e rimanere compliant? Come ci può aiutare in tutto questo il M.E.D.S. (Method for Efficient Development of Software)?

Ne parlerò a Monaco, alla conferenza Aerospace Testing Europe durante la Aerospace Tech Week:

Come ogni anno, sono invitato a presentare delle soluzioni più efficienti per la Certificazione Avionica (e di conseguenza tutte le altre), quest’anno mi concentrerò su un compito apparentemente “impossibile”: dimostrare proprio come la Metodologia AGILE, che in teoria mal si presta al mondo “sicuro”, in realtà se ben usata può aiutare le aziende come la tua a vincere la sfida col Software Certificato, aiutandoti a essere più snello e rapido senza nessun sacrificio sulla Safety.

In poche parole, come il M.E.D.S. riesce a mettere insieme il Safety- e il Business-Critical.

Scopri la mia “sfida” impossibile partecipando alla mia presentazione a Monaco il 7 Marzo alle 14!

Se ti prenoti a questo link:

https://www.softwaresicuro.it/Mautic/software-sicuro-il-libro

potrai nell’occasione ricevere di persona una copia autografata (e ancora per poco gratuita!) del mio libro “Software Sicuro”, anche in inglese!

WEBINAR GRATUITO

Giovedì 7 Marzo 2019 – ore 14:00

Che cos’è un Requisito Perfetto? Come si fanno a scrivere dei buoni Requisiti Software?

Facciamo un passo indietro, anzi di lato:

Inizieresti a realizzare una casa con un progetto “approssimativo”?
Senza fare calcoli strutturali e simulazioni?
Senza un capitolato che specifichi bene tutti i costi previsti?

Sai benissimo che è impossibile, perché lasceresti troppa libera scelta al costruttore, con il rischio certo di un risultato non soddisfacente e di conseguenza la necessità di apportare modifiche in corso d’opera e rifacimenti di quanto già realizzato con spreco di tempo e denaro…

Nello stesso modo, da costruttore eviteresti di accettare un lavoro del genere, fatto di una chiacchierata ed una stretta di mano, perché sai che darebbe luogo ad infinite contestazioni e richieste da parte del cliente.

Lo stesso discorso vale per un prodotto software: senza requisiti chiari e funzionali, si avrà una soluzione non efficiente con conseguente bisogno di interventi in itinere per “interpretare” quello che il cliente vuole e che non è stato chiarito in partenza. 
Risultato: mancanza di efficienza, ritardo nei rilasci e malcontento del cliente (e del fornitore!).

La stesura corretta e consapevole dei requisiti non è da considerarsi una perdita di tempo ma una vera e propria “scienza” che detta le regole per la costruzione delle fondamenta di un software che, come per una casa, sono un elemento imprescindibile per un risultato finale ottimale.

Il webinar gratuito sul “Requisito Perfetto”

Scopri “I DIECI COMANDAMENTI DEL REQUISITO PERFETTO”, in un webinar gratuito che si terrà:

GIOVEDI’ 7 MARZO alle ore 14:00

Durante questo webinar, ti spiegherò tutte le tecniche per costruire dei requisiti a prova di bomba, senza che questo appesantisca troppo il tuo ciclo di vita del software, ma in modo da stabilire un vero e proprio “capitolato” con i tuoi clienti.

Ovviamente, se poi devi adeguarti a qualunque Certificazione Safety-Critical… questo webinar è a dir poco fondamentale. Se applicati in maniera integrale e rigorosa, questi 10 Comandamenti diventeranno gratuitamente per te una vera e propria Requirement Guideline, da cui ricavare a sua volta la Checklist che potrai usare per raggiungere senza problemi la certificazione!

Come fare a iscriverti?

Per partecipare al webinar, devi compilare questo modulo:

Invita pure chi vuoi!

Estendi l’invito a questo webinar a colleghi, amici ma se riesci anche a clienti e fornitori… più persone nella tua filiera impareranno l’importanza di scrivere al meglio i requisiti, così come previsto nello standard M.E.D.S., più facilmente lavorerete insieme per la produzione di software migliore da tutti i punti di vista.

Ti attendo al webinar Giovedì 7 Marzo alle 14:00!

Massimo

Corso di Certificazione Avionica DO-178C

Roma 14-16 Novembre

 

Sei uno sviluppatore di codice Safety-Critical?

Sei il manager di un team di sviluppo di un’azienda aerospaziale, automotive, medicale?

Hai un’azienda che vorrebbe debuttare nel difficile settore del software certificato?

 

In questo breve video ti spiego alcuni concetti fondamentali, che verranno ampliati durante il corso completo di 3 giorni sulla Certificazione Avionica che si terrà il 14-15-16 Novembre 2018 a Roma.

 

Cosa imparerai da questo corso

Imparerai da esperti a livello mondiale come Vance Hilderman, una delle principali autorità della certificazione

aerospaziale DO-178 e da Massimo Bombino, colui che è riuscito con successo ad applicare le metodologie di sviluppo del codice più efficienti e moderne al software Safety Critical, come fare a:

Read More

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

AGILE e DO-178: quali sono gli aspetti di queste che sono tra le migliori metodologie di sviluppo che si sono affermate negli ultimi anni sul mercato e che vogliamo selezionare accuratamente in modo da prenderne il meglio?

Quali sono all’interno di questi due mondi, AGILE e DO-178, diciamo i migliori nel loro ambito ma imperfetti o troppo specializzati per essere applicati ovunque, le idee e le tecniche migliori che vogliamo cannibalizzare e parassitare, per piegarle a nostro piacimento?

Come possiamo sfrondare di orpelli, attività burocratiche e inutili, o inefficienti e costose, due processi altamente diffusi nel mondo del software in modo da ottenere una nuova sommatoria che è (quasi) perfetta?

Ecco, questo lungo articolo andrà a esaminare due metodologie molto conosciute da (quasi) tutti: il metodo AGILE e la Certificazione Avionica DO-178.

Due tecnologie mature, complete, ricche di un sacco di aspetti interessanti ma a volte burocratiche, ridondanti, inefficienti. O al contrario sbrigative, superficiali, incomplete.

Per cui andiamo a fare un po’ di cosiddetto cherry-picking e selezioneremo uno per uno gli aspetti, i principi, gli obiettivi principali dei due mondi e decideremo se portarli con noi e in che modo, se integralmente o con giudizio.

E ne tireremo fuori una metodologia nuova e a prova di bomba, da adottare in qualunque tipo di sviluppo, normato e certificato quindi Safety Critical, ma anche e soprattutto in quello normale, quotidiano del mondo Business-Critical.

 

Read More