AGILE E DO-178: UN MATRIMONIO (IM)PERFETTO?

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.

METODO AGILE

AGILE lo conoscono tutti, dai. E’ diventato il metodo più celebre di produzione del software, almeno a livello di nome, superando di popolarità il vecchissimo Waterfall o il moderno Ciclo a V.

Ma… AGILE è veramente conosciuto nei dettagli o solo di nome o peggio ancora di fama?

E che fama ha… ne hai sentito parlare in termini polarizzati, quindi o troppo entusiastici o troppo drammatici?

La verità come sempre sta nel mezzo:

Il metodo AGILE si propone come approccio… appunto agile al mondo complesso e mutante dello sviluppo software, in contrapposizione a quello ingessato e pesante del Waterfall ma tende a essere poco adatto ad approcci rigorosi e critici.

Questo vuol dire che dobbiamo buttare via il bambino e l’acqua sporca? Non sia mai: cerchiamo di capire quali sono gli approcci interessanti di AGILE e quali invece dobbiamo buttare se vogliamo veramente essere ingegneristici e precisi, come richiesto dal software Safety- e Business-Critical pur rimanendo efficienti.

Partiamo dai 4 principi di base e cerchiamo di capire come nel gioco della torre quali buttare giù.

Questi principi di AGILE sanciscono che bisogna dare “valore” (sigh, poi vi spiego il perché di questo lamento) a:

Individui e interazioni piuttosto che processi e tool: questa affermazione può anche sembrare apparentemente intelligente, pur pensando che ovviamente i PROCESSI sono fondamentali nel mondo della certificazione e in generale della Qualità, ma è facilmente smontabile da un’evidenza sotto gli occhi di tutti, gli individui si licenziano. Prima o poi se ne vanno, cambiano ruolo, mutano responsabilità per cui basarsi solo sulle persone e non sui processi è semplicemente folle. Teniamo buona però la parte sulle interazioni che svilupperemo dopo. I tool invece sono funzionali a quello che bisogna ottenere.
Software funzionante invece che documentazione completa: anche qua, le due cose assolutamente devono coesistere, in un approccio che sia ingegneristico e sicuro. Il software funzionante è fondamentale: per questo motivo, come vedremo, l’importanza di AGILE al TEST deve essere assolutamente capitalizzata. Ma la documentazione… è talmente importante che questo punto suona quasi come eretico a chi deve certificare o produrre qualità e farebbe bene a ritenere l’affermazione molto contestabile.
Collaborazione col cliente invece che negoziazione di contratti: questa è forse la cosa da smontare più radicalmente… o meglio, come sempre la parte di sinistra di queste alternative è sempre golosa, peccato per quel “invece che”. No: possiamo e dobbiamo coinvolgere il cliente, farlo partecipe del ciclo di vita, rendere più snelli i contratti, la stesura dei requisiti ma deve essere fatto mettendo anche dei paletti, delle iterazioni e prototipazioni concordate e congelate, dei report frequenti e interattivi.
Rispondere al Cambiamento invece che seguire un piano: stesso difetto… prima parte sacrosanta. Il Cambiamento è una costante dei progetti software e ci deve essere in modo di gestire il cambiamento. Infatti, la tecnica della Continuous Integration e Continuous Testing le cannibalizzeremo a piene mani. Ma i Piani… dovranno assolutamente essere fatti bene, precisi, rigorosi. Certo, ci sarà lo spazio per la flessibilità… per prototipi, per iterazioni, per rilasci intermedi. Lasciando però la necessità anzi l’obbligo di rispettare certi standard, certe milestone, certe rigidità da introdurre solo dove necessario.

E delle varie tecniche e pratiche suggerite da AGILE, cosa andremo a salvare e a far confluire nel nostro metodo?

Automazione: questo è poco ma sicuro, automatizzare tutto, (quasi) ad ogni costo. Soprattutto la cosa più facilmente automatizzabile, da ripetere molto frequentemente se non ogni giorno, che rappresenta la migliore se non l’unica misura di quanto il software risponda ai requisiti e si comporti correttamente: il TEST. Automatizzare i test dovrebbe diventare una vera e propria religione.
Interazione: questa non può che fare bene. Interazione con il cliente, nel gruppo di lavoro, tra team di sviluppo e di test, eccetera non possono che far crescere la consapevolezza, la cultura e quindi la qualità del lavoro fatto, così come aiutano a ridurre la catena di feedback e a capire subito se qualcosa non va, invece che all’ultimo.
Conoscenza e cultura: come raccontavo nell’articolo sulla Cultura del software, un lavoro continuo e integrato del team e basato su leadership tecnica, workshop, Hackathon, task force, Gap Analysis ecc. è assolutamente salvifico e fondamentale per aumentare la qualità del lavoro fatto insieme.
Iterazioni: qua bisogna fare attenzione… si parla in AGILE tanto di consegne MOLTO frequenti, forse fin troppo. Ok con le iterazioni… ma pianificate, con un piano preciso di rilascio, con la corretta priorità di funzionalità e requisiti consegnati a ogni step.
Modellazione: assolutamente un caposaldo del software moderno. Il Model-Driven Development basato su approcci standard come UML, SysML, MARTE oppure utilizzando tool proprietari consente risparmi di tempo pazzeschi rispetto a fare tutto da zero, pur conservando la qualità e maneggevolezza del software prodotto.
Programmazione in coppia: altro principio sanissimo e da applicare a tutto il ciclo di vita. “Two is megl che uan”, diceva una pubblicità. La review continua e integrata di ogni lavoro fatto da parte di un altro componente del team è molto positiva, a patto che sia fatta con un minimo di rigore e di pianificazione, magari tramite Checklist.
Test (Driven Development): test, test e ancora test. La chiave del successo di ogni iniziativa di sviluppo software. Riuscireste a pensare a un libro best-seller che non passi attraverso vari correttori di bozze e editor? O a una casa, un ponte, un palazzo che non sia testato tramite sollecitazioni statiche e dinamiche? Prendiamo il famoso TDD ovvero Test-Driven Development: scrivere i test basandosi sui requisiti, prima che il codice sia pronto, è… semplicemente fantastico, perfetto. Così come il concetto di Continuous Testing and Integration… queste ce li prendiamo e ce li portiamo a casa tutti così come sono.
Versionamento: questo è un altro principio che adottiamo senza remore. L’uso di un CMS (Configuration Management System) è tra i primissimi acquisti e priorità in assoluto di un processo di sviluppo software moderno, ma si deve estendere a TUTTI i manufatti di qualunque tipo: requisiti, documenti, codice, test, procedure ecc.

Quello che invece NON salviamo e che dobbiamo rapidamente dimenticare di AGILE, l’abbiamo in pratica menzionato…

NO a eccessiva prototipazione, iterazione, rilasci troppo brevi e frequenti
NO all’eccessiva personalizzazione dei ruoli e delle attività
NO a documentazione scarna e rilasciata all’ultimo
NO al reverse-engineering o comunque grossa limitazione
NO alle modifiche all’ultimo minuto che non passino attraverso tutte le fasi d’impatto e verifica necessarie

Perciò dai… direi che non siamo messi così male, no?

Buona parte dei principi AGILE sono molto validi, di sicuro hanno un fondamento molto utile ma magari si perdono in contraddizioni che vogliamo evitare, oppure danno troppa poca importanza a certi aspetti fondamentali quando si vuole usare un approccio scientifico e ingegneristico al software, che sia nello stesso tempo agile come il metodo stesso vorrebbe. Perciò, con cautela e qualche eccezione… possiamo abbastanza applicarli.

Mentre delle tecniche… direi che quasi tutte quelle di AGILE sono MOLTO interessanti! Sono tecniche che permettono in effetti di rendere tutto il ciclo di vita del software molto più automatico, ripetibile, controllato, rapido e soprattutto sicuro il software che facciamo.

E questo ci fa molta ma molta gola… perché ci consentirà di ridurre in maniera sensibile i costi e i tempi, ma nello stesso modo magicamente ci aiuterà a incrementare la qualità di quello che produciamo, che andrà a incidere non tanto sui costi immediati ma su quelli futuri, di manutenzione e di supporto sul campo del tuo software.

Vediamo ora invece la parte della certificazione avionica, che fa molta più paura (da fuori) per la sua rigidità e per i suoi costi, ma che come vedremo unito ad AGILE ci darà in cambio una serie di enormi vantaggi anche per la tua azienda… anche se sviluppi software del tutto innocuo (per le persone) ma non per il business altrui (e quindi di conseguenza anche per il tuo!).

CERTIFICAZIONE AVIONICA DO-178

La certificazione avionica è in assoluto la più temuta: considerata alla stregua delle forche caudine, è considerata terribile e dispendiosa, non a torto direi. Il budget di un progetto “normale” certificato con standard diversi o addirittura non certificato, può lievitare anche del 200 o del 300% se l’azienda volesse procedere lungo il percorso della DO-178, senza tra l’altro nessuna garanzia di riuscita e soprattutto una difficile gestione e previsione dei tempi.

Qual è la contro-partita?

Bene: nel 2017, non c’è stato NESSUN INCIDENTE MORTALE con aerei di linea. NESSUNO.

E’ sufficientemente chiaro?

Pensate a queste cose:

ad un telefonino, che per un intero anno non ha app che falliscono rovinosamente
ad un computer, che per 12 mesi non ha nessun crash e perdita di dati
ad un sito Internet, che trovate sempre attivo 24 ore su 24 senza interruzioni, ritardi, pagine perse

Sarebbe bello, eh?

Peccato che è stato calcolato che un ipotetico telefonino DO-178 compliant potrebbe costare fino a 20-30.000€ se non di più (sì, TRENTAMILA EURO). E ogni singola applicazione migliaia di euro.

Ok, va bene, ti faccio una domanda:

“Ti accontenteresti di produrre un telefonino, un’app, un programma per computer, un sistema embedded, molto più affidabile, performante, sicuro al prezzo di un contenuto e ragionevole incremento dei costi? Ma risparmiando poi molto di più in termini di manutenzione, supporto, costi di assistenza?”

Se la risposta è NO: hai sbagliato articolo, continua pure a spendere poco, pochissimo nello sviluppo e a bruciare capitali ingenti, non prevedibili e fuori controllo nell’assistenza e supporto post-vendita e a gestire le cattive referenze di clienti incavolati neri. AUGURI.

Se invece vuoi scoprire come fare a:

sfruttare a tuo personale vantaggio i punti salienti della certificazione avionica DO-178
applicare i principi fondamentali in un ambiente safety-critical non avionico o anche solo business-critical
lasciar perdere tutte la burocrazia, attività ridondanti e inutili per la tua azienda
ottenere un incremento incredibile della qualità del tuo software a fronte di un piccolo investimento nel processo di sviluppo
risparmiare alla fine un sacco di soldi considerando tutto il ciclo di vita compreso supporto e assistenza sul campo

allora è il caso che continui a leggere, perché i principi più sani ed efficienti della certificazione DO-178 che hanno ispirato il METODO PER UN EFFICIENTE SVILUPPO DEL SOFTWARE (M.E.D.S.) molto probabilmente fanno al caso tuo.

Ok, ora rispondo alla domanda fondamentale che ti frulla in testa:

“Quali sono i principi fondamentali della certificazione avionica secondo lo standard DO-178 che eventualmente vale la pena di tenere e adottare, e quali invece butto dalla torre?”

Vediamoli uno per uno:

LIVELLI DI SICUREZZA: uno degli aspetti fondamentali della Certificazione Avionica DO-178 è quello del livello di sicurezza, chiamato Design Assurance Level (DAL). Per farla breve, si divide in 5 livelli dove la percentuale di errore del software, calcolata in maniera del tutto teorica e non misurata realmente, va da 10E-09 ore di voli per il Level A, fino a 10E-03 del Level E. Esatto, un errore ogni miliardo di ore di volo. Lasciando a questo altro articolo una spiegazione delle motivazioni e conseguenze reali di questo aspetto, facciamo un discorso più pragmatico. Capiamo da soli che un software di livello A è molto più sicuro ma anche più caro di un software di livello E, che potremmo considerare un normale software applicativo che gira sul nostro computer o telefonino. Per cui, cosa succederebbe se lasciassimo libera iniziativa alle aziende aeronautiche senza imporre nessun vincolo? Ci sarebbero aerei con solo software di livello E che si schianterebbero un giorno sì e uno no. E se invece fossero le autorità certificative statali o comunitarie a fissare da sole i paletti? Avremmo tutti aerei di livello A, super-costosi e super-sicuri ma dove il biglietto costerebbe decine o centinaia di migliaia di euro. E’ quello che vogliamo? Assolutamente no: per quello che si sono fissati i livelli! Perciò, un’attività ben precisa di Safety Assessment, effettuata in più riprese e modalità, assegnerà ad ogni sistema, ad ogni componente, ad ogni software un livello di criticità apposito. Per cui, questa classificazione dei miei sistemi di bordo a seconda dei livelli di criticità rappresenta il miglior compromesso in assoluto tra costi e sicurezza. Ha senso tutto questo al di fuori dell’avionica? Ha senso sì nella certificazione Safety-Critical in generale: anche nel mondo ferroviario, automobilistico, medicale ecc. esiste una classificazione in livelli assolutamente analoga. Al di fuori di questi mondi certificati e normati, ha senso? No, non molto… sicuramente però posso avere delle linee guida simili, più morbide, per le quali decidere le attività che devono essere svolte per un certo tipo di software, e quelle che invece non debbo necessariamente fare.
DETERMINISMO: questo di fatto è uno dei principi più importanti e più ingombranti della certificazione avionica. Per darvi un’idea immediata e comprensibile: nel mondo della certificazione, da pochissimi anni (3-4 al massimo) si sono affacciate tecnologie considerate… disruttive, come l’Object Oriented, il Model-Based, i Metodi Formali e linguaggi “avveniristici” come il… C++. Vi rendete conto di quanto siano conservatori in questo mondo? Ok, va bene essere attenti, prudenti, attenti alle conseguenze di qualunque scelta ma come sappiamo benissimo il mondo non avionico è andato avanti anni-luce e ha prodotto una quantità notevole di innovazioni tecnologiche, di tool, di linguaggi. Cosa vuol dire, che va bene tutto? No: per niente. Non è il caso di fare da sperimentatori per gli ultimi capricci delle case produttrici di tool, non è bello da fare da beta-tester di tecnologie immature e via discorrendo. Forse è il caso di avere un atteggiamento di giusta prudenza e adottare tecnologie che siano abbastanza mature, pur fornendo dei vantaggi misurabili.
PIANIFICAZIONE: ok, la parte dei “famigerati” piani della DO-178 è una delle più temute in assoluto, perché come chi è passato dalla tortura… ehm dalla certificazione, sa che l’approvazione dei piani tipo il famoso PSAC (Plan of Software Aspects of Certification) è in assoluto il primo e il più difficile scoglio. Bene, sgombriamo il campo da equivoci: la pianificazione va bene, ma i famosi 5+5 piani della certificazione (5 software, 5 hardware) sono veramente fin TROPPO per noi. Sì, adotteremo alcuni dei principi sani di pianificazione, ma qua c’è veramente tanto da sfrondare
QUALITA’: nel mondo dell’avionica, esiste una figura tanto delicata e importante, quanto temuta. Quella del Quality Assurance Manager (QAM). Un vero e proprio direttore d’orchestra: non deve saper necessariamente programmare, non deve sapere effettuare dei test ma è quello che dirige il lavoro di tutti, verificando modi, tempi, conformità e garantendo all’autorità il rispetto dei piani. Sovrabbondante: un Responsabile della Qualità è importante in tutti i settori, anche non avionici, ma non necessariamente al livello di parossismo richiesto dalla DO-178, a meno che tu sia obbligato dalla Certificazione, si intente. Per cui Qualità sì, ma con Equilibrio.
PROCESSO: beh certo, il processo è talmente importante nel mondo avionico che è l’essenza stessa della certificazione. L’adesione incondizionata, totale e senza eccezioni ai 71 obiettivi della certificazione DO-178 è semplicemente obbligatoria. Senza eccezioni. Noi cercheremo di sviluppare in questo articolo e nel libro in uscita un nuovo metodo e approccio, più volte citato e chiamato METODO PER UN EFFICIENTE SVILUPPO DEL SOFTWARE (M.E.D.S.), ma lasceremo un certo grado di flessibilità e di progressione nell’applicarlo. Ma attenzione: non perché non serva, o sia ridondante, applicarlo tutto. Anzi. Semplicemente per dare a te, lettore, la possibilità di applicarlo secondo i tuoi tempi, perché a ogni passo saranno talmente tanti i vantaggi che troverai nel breve e lungo periodo, che troverai un tale ritorno dell’investimento che vorrai applicarlo integralmente il prima possibile, ma per TUA personale scelta di risparmio ed efficienza.
REQUISITI: ecco, i requisiti sono FONDAMENTALI. E’ sufficientemente chiaro? Sono FONDAMENTALI! Rinunciare a dei requisiti fatti bene è una tale zappa sui piedi, una tale disgrazia, un tale atto di auto-lesionismo che se non hai intenzione di cambiare radicalmente il modo di gestire i requisiti del tuo software quanto prima come cosa prioritaria, ti consiglio vivamente di cambiare metodo, approccio. Di interrompere qui la lettura. Oppure continuare e capire perché questo è un tassello fondamentale della tua strategia alla fine per spendere MENO per il tuo software. Poi la certificazione avionica ti suggerisce di avere una differenziazione tra requisiti di alto e di basso livello, ma noi non adotteremo questo duplice livello se non ne siamo costretti. Ma tutto il resto… è oggetto di un altro articolo dedicato che ti invito ad andare a leggere con cura. Ti aspetto qui.
CRITERI DI TRANSIZIONE: quando ho completato un’attività di scrittura dei requisiti? Quando posso iniziare a testare? Che documenti mi servono per partire con lo sviluppo? Quali sono i risultati di un’attività di pianificazione dei test? Queste sono alcune delle tante domande a cui corrispondono i famosi Transition Criteria della certificazione avionica. In maniera quasi parossistica, lo standard DO-178 definisce decine e decine di criteri di transizione: praticamente per ognuna della attività, vengono definiti tutti i documenti e i dati in ingresso, il momento esatto in cui deve partire il lavoro, quali sono i risultati attesi e qual è il momento in cui l’attività deve ritenersi conclusa. Cosa salviamo di tutto questo lavoro? Di certo, possiamo semplificare il numero totale di attività che sono fin troppo segmentate nell’ambito avionico e possiamo essere meno rigorosi nel definire tutti gli ingressi ed uscite, ma rendere più rigoroso il metodo tramite una chiara idea delle attività da svolgere, quando vanno iniziate e quando sono da considerarsi terminate e cosa producono come risultato, è in ogni caso un valore aggiunto che responsabilizza i vari attori coinvolti. Da usare con moderazione, ma salviamo anche questo.
CHECKLIST: un aspetto meno noto e fondamentale della certificazione avionica, anche se profondamente legato ai criteri di transizione, è sicuramente quello delle checklist. Cosa vuol dire? Normalmente, qualunque attività nel mondo del software (e in mille altri ambiti) si ispira a dei principi fondamentali che vengono seguiti in maniera più o meno fedele, ma di fatto molto difficile da controllare. L’iniziativa personale, il contributo dell’esperienza del singolo, l’aggiunta di ispirazione e creatività dello sviluppatore e del professionista rendono la maggior parte delle attività, della loro pianificazione e della loro verifica molto differenziate e poco ripetibili. Quindi poco ingegnerizzate, cosa che il metodo M.E.D.S. aborre… Per cui, cosa servono le Checklist? Servono a fare in modo che qualunque attività e sua transizione, tipo Pianificazione, Sviluppo, Test, Review ecc. segua dei principi ispiratori ben precisi e codificati in una serie di domande e risposte che bisogna OBBLIGATORIAMENTE seguire, almeno per quanto riguarda la certificazione avionica classica. Perfetto. Cosa facciamo, adottiamo queste checklist anche noi? Certo, perché no? Magari meno rigorose, meno dettagliate, meno invadenti… ma come spiegheremo in dettaglio, delle checklist aiuteranno a ridurre il contributo personale, creativo per cui non ripetibile, ingegnerizzabile dei tuoi collaboratori. E questo è SOLO UN ASPETTO POSITIVO. Perciò… parliamone: delle checklist fatte bene, snelle ed efficienti, aiuteranno soprattutto a raggiungere un livello di review sistematico e ripetibile, e le troveremo indispensabili n caso di avvicendamento e rotazione del personale.
VERIFICA (REVISIONE, TEST,ANALISI): vabbè, gli avionici in quella che chiamano Verification, comprendono anche le attività di Review che pesano molto e quelle di Analisys che coprono i casi limiti in cui il Test non arriva, ma alcuni dati parlano molto chiaro: di 71 obiettivi della DO-178, la bellezza di 41 obiettivi sono relativi alle attività di Verifica. Esatto: il 60% degli obiettivi e indicativamente anche dell’effort, dei costi e del tempo sono dedicate ad attività che comprendono appunto la magica triade. Andiamo ad esplodere i tre contributi nella loro importanza al di fuori del mondo avionico, non senza qualche sorpresa.
REVISIONE: nel mondo avionico, qualunque tipo di documento, requisito, codice, dato ecc. è sempre e comunque soggetto a un’attività di Review. Non si scappa: anzi la procedura di rilettura, revisione di qualunque tipo di documento o dato è rinforzata dall’imposizione del criterio di Indipendenza, per cui colui che fa la Review di qualunque attività non è la persona che l’ha effettuata. Molto diverso da come si intende normalmente l’indipendenza nel mondo del software: di solito si intende ad esempio che chi fa i requisiti deve essere diverso da chi fa il codice, la stessa cosa chi fa i test rispetto a chi fa sviluppo Bene: la DO-178 invece impone la sola indipendenza del revisore, la cosiddetta Peer Review. Concetto che ci piace, non ci costa niente tanto comunque la revisione dobbiamo farla lo stesso, tanto vale farla fare da qualcun’altro che troverà sicuramente più errori di noi stessi. Se poi vogliamo aggiungere l’indipendenza anche tra le attività, perché no?
TEST: c’è bisogno di aggiungere altro? Il Test è la vera e unica attività insostituibile per verificare, misurare e per migliorare la qualità di un software. E’ un’attività che ti porterà come minimo a raddoppiare inizialmente il tuo budget di sviluppo. Esatto, hai capito bene: a RADDOPPIARE IL TUO BUDGET. Chi al momento ad esempio di acquisire un tool di test si lamenta del costo di poche migliaia di euro, non ha idea che il budget di test sarà enormemente maggiore ed il costo è prevalentemente quello umano di sviluppo dei test. Del resto, è l’unico modo che abbiamo per sapere se abbiamo costruito esattamente quello che ci ha chiesto il cliente. Quello che dovevamo fare e non quello che ci siamo messi in testa di fare. Qua ci sarebbe da scrivere per mesi, per anni anzi e infatti dedicheremo più di un articolo a questo argomento. Qua ricapitoliamo velocemente che non basta solo parlare di test: si parlerà di Test Plan e strategia, di Procedure di Test, di Test Normali e di Robustezza quindi di test nel normale range operativo e in quello eccezionale; si parlerà di vari livelli di test, dai Test di Basso Livello, passando dall’Integrazione Software-Software fino all’Integrazione Hardware-Software. Tutto soggetto a revisione indipendente. Perciò non stiamo ora a scendere in dettaglio di cosa salviamo per i nostri scopi e di cosa no, ma sicuramente gran parte della strategia avionica di test è nostra assoluta ed indissolubile amica.
ANALISI: questo è un aspetto molto particolare della DO-178 e non è certo di nostro particolare interesse, se non in casi molto particolari. Si sta dicendo questo: quando non sei in grado di validare qualcosa, non riesci a testarlo, insomma hai difficoltà a verificarlo, allora puoi dimostrare la tua affermazione, requisito, test con un’attività di analisi ingegneristica, quindi umana. Esempio: non riesci a misurare sul campo reale che un certo algoritmo ci metta al massimo 10 millisecondi in tutte le condizioni? E allora fai un’analisi manuale, verificano a mano dall’assembler e contando il numero dei cicli macchina. E via discorrendo. Quindi è un concetto molto generico e da utilizzare solo in casi veramente specifici, quando è richiesta una prova per validare una certa teoria. Molto raramente si usa altrove, ma teniamone almeno conto.
COPERTURA: questo è un altro concetto molto importante, che ha una priorità abbastanza alta nella scaletta di adozione del METODO PER UN EFFICIENTE SVILUPPO DEL SOFTWARE (M.E.D.S.), in modo da incrementare molto velocemente la qualità dei prodotti che vendi e che contengono software. Di cosa si tratta? Si tratta di misurare in tempo reale, durante i tuoi test soprattutto funzionali e di sistema, quindi in ambienti reali o realistici, la copertura del tuo codice in termini di linee eseguite (Statement), di scelte tipo IF-THEN-ELSE eseguiti sia nel ramo True che False (Branch) e di coppie di variabili indipendenti (MC/DC). Qual è l’obiettivo da raggiungere per la DO-178? Semplice: a seconda del livello di criticità, viene richiesto di aderire alla copertura di Statement, Branch o MC/DC a livello del 100%. Esatto: CENTO PER CENTO. Per cui tutto il software che vola deve essere completamente coperto durante i test. Ma qual è il motivo, avete mai riflettuto? Ok, sicuramente è anche una questione di esecuzione accidentale di software non previsto. Ma il motivo principale per cui anche tu non dovresti vendere software che non ha raggiunto percentuali di coverage molto alte è ancora più semplice: il software non coperto, è quello non testato. E il software non testato ha un sacco di bug. E indovina chi andrà a testare e scoprire tutti questi errori? Esatto, il tuo tester più bravo, efficiente ma costoso: il tuo cliente finale. E lo sai benissimo come funziona: i tuoi clienti sono fantastici a creare situazioni anomale, non previste, a schiacciare il bottone sbagliato al momento sbagliato, a fare tutto quello che OVVIAMENTE tu che hai creato il prodotto non faresti mai, ma lui sì. E il cliente se ha un problema, un crash, un danno o ancora peggio se si ferisce e addirittura muore per colpa dei tuoi bug, farà una cosa molto semplice (o gli eredi per lui): ti chiederà un sacco di soldi per ogni errore che trova o smetterà di pagarti e ti manderà in rovina. Ti serve altro per accogliere il principio del Coverage nella tua strategia di sviluppo?

Conclusioni: AGILE o DO-178?

Ecco, abbiamo quindi visto come da questi due metodi normalmente applicati in uno specifico contesto non sempre applicabile, possiamo tranquillamente estrarre alcuni principi ispiratori di AGILE, alcune tecniche e metodologie di DO-178 che sono applicabili in qualunque ambito, anche non certificativo.

conservando la flessibilità e scalabilità del metodo ma nello stesso tempo un necessario rigore

Sta per uscire il mio nuovo libro “Software Sicuro”, dove andrò ad approfondire la maggior parte di questi punti. Per essere informato in anteprima sulla sua uscita o per riceverne una copia, scrivi a: blog@softwaresicuro.it