Stai proteggendo il tuo Business dai rischi dello Sviluppo Software?

Mi capita molto spesso di parlare con molti di voi professionisti che si occupano di sviluppo software a vari livelli (sviluppatori, manager, imprenditori) e spesso mi confronto con una preparazione tecnica ineccepibile, eccezionale: molto spesso migliore della mia! 

Avendo lavorato pure io per oltre vent’anni nel puro sviluppo software critico, in settori come telecomunicazioni, aerospaziale, automazione industriale e altri ancora, soprattutto agli esordi e per parecchi anni a seguire, mi sono sempre sentito sicuramente un vero “nerd” su tanti argomenti, nel senso positivo di sviluppatore appassionato e sempre aggiornato su qualunque novità e innovazione, con la sensazione di essere imbattibile nel mio settore. Anche se poi purtroppo ho dovuto smettere di seguire alcune di queste tecnologie, perché rimanere aggiornati risulta sempre più difficile, in quanto si spende un sacco di tempo per altre attività più “noiose” e burocratiche e nel frattempo la tecnologia corre molto veloce.

Infatti, chi lavora da anni quotidianamente immerso in un settore specifico, applicando sempre più spesso la stessa tecnica, un tool, un linguaggio sviluppa una padronanza tale della materia da avere letto più o meno tutto quello che esiste sull’argomento, sperimentato varie soluzioni e alla fine si sente circondato da un’aura di sicurezza, di confidenza che d’altra parte è del tutto motivata, sia dalla teoria che dai fatti. Difficile se non impossibile prenderli in fallo: d’altronde, anche nel tuo specifico caso… sei giustamente convinto che, nel tuo lavoro, te la cavi piuttosto bene e non hai bisogno di consigli, giusto? 

Ecco, questo è un po’ quello che mi capita quotidianamente, lavorando con tanti clienti diversi in vari settori:

spesso uno si ritrova un po’ chiuso nel suo habitat tecnologico e informativo, convinto di sapere esattamente quali sono i propri punti di forza e le debolezze sulle quali lavorare e sviluppa una sorta di diffidenza, di chiusura verso apporti esterni di esperienza, di consigli, se non addirittura di corsi o consulenze che vengono ritenute inutili e superflue

con il rischio di essere inavvertitamente esposti ai rischi continui e inaspettati legati allo sviluppo del Software e la conseguenza di mettere in pericolo il proprio Business (da cui il concetto di Business-Critical)

In realtà, ci sono almeno due aspetti aggiuntivi che nulla tolgono alla competenza e capacità tecnologica nel proprio settore specifico, ma che sono fondamentali per gestire i variegati rischi relativi allo sviluppo di codice e di conseguenza per poter rispondere alla incredibile complessità dello sviluppo software, che rimane l’attività umana intellettiva più complessa in assoluto: in termini di numero di giorni/uomo, un qualunque software applicativo neanche troppo sofisticato batte senza problemi la complessità, la varietà, il tempo impiegato nella creazione anche di grandi opere come la Divina Commedia o la Cappella Sistina.

Di seguito, cercherò di spiegarvi come la mia esperienza costellata di errori, di passi falsi, di pessime esperienze sia stata implementata con una serie di suggerimenti, di strategie prima appresi da studi teorici, da Master, da approfondimenti, poi sperimentati negli anni su vari fronti e infine distillati in un metodo che potrebbe rivelarsi fondamentale su come fare a cambiare rotta e a gestire tutti gli aspetti critici dello sviluppo applicativo.

Vediamo quali sono questi due approcci fondamentali ma che chi è troppo immerso negli aspetti puramente tecnologici e specifici del settore tende a trascurare, preso com’è dalla quotidianità e dalla fretta di consegnare, di soddisfare il cliente, di rispondere al management.

Read More

La via AGILE alla Certificazione Avionica del Software

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:

https://www.aerospacetechweek.com/aerospace-testing-europe-conference-programme/

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!

Software Sicuro: il libro!

E’ uscito il mio primo libro!!

SOFTWARE SICURO

COME SVILUPPARE SOFTWARE SICURO E STABILE IN MODO EFFICIENTE, RIPETIBILE ED ECONOMICO

 

TRASFORMA LO SVILUPPO SOFTWARE DA RISCHIO E COSTO, A VANTAGGIO COMPETITIVO STRATEGICO. ANCHE SE NON HAI ESPERIENZA SPECIFICA.

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?

 

Per avere una copia gratis:

info@softwaresicuro.it

 

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

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.

 

Read More

Il segreto su come battere la concorrenza dei paesi low-cost nel software

Oggi vincere la sfida contro i paesi emergenti low-cost nel campo della produzione di software e firmware non è cosa facile. Quasi tutte le PMI, dopo la crisi del 2008, hanno subito profondi cambiamenti e hanno dovuto reinventare un metodo diverso per sopravvivere a queste potenti economie in espansione.

Dopo la crisi molte piccole e medie aziende di produzione di sistemi dove la componente software ha un peso crescente, hanno sperimentato la guerra dei prezzi provenienti da queste nuove economie, che spesso sono generate non solo dal bassissimo costo della manodopera seppur qualificata di ingegneri e tecnici, ma anche da politiche di aiuto statale dei paesi stessi.

Oltre a subire questo attacco a livello economico, spesso aziende spregiudicate si sono copiate anche i nostri marchi, incuranti di ogni brevetto o registrazione. Ho un cliente che ha addirittura subito una causa legale negli USA perché il suo distributore ufficiale lo ha portato in tribunale per aver venduto direttamente sul mercato a clienti finali senza riconoscere una commissione al distributore. Alla fine il risultato è stato che erano stati dei cinesi a copiare talmente bene il prodotto, con funzionalità apparentemente identiche, marchio e imballo incluso, che persino il distributore non si era accorto della truffa!!

Chissà quante altre storie probabilmente anche tu stesso hai vissuto o sentito raccontare, aziende ridotte a dimezzare o chiudere definitivamente per via di questa concorrenza sleale, basata sullo sfruttamento delle persone abbinato a politiche di aiuto statale dei paesi stessi.

Quando sei investito da questo tipo di concorrenza, all’inizio provi a resistere facendo la cosa apparentemente più logica: abbassare il tuo prezzo! Si inizia sempre in questo modo, ovviamente abbassare il prezzo è l’arma più immediata che hai a disposizione, ma anche la più pericolosa.

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

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