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