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

 

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

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

La cultura, questa sconosciuta! (prima parte)

La cultura è importante, ce lo ripetono fin da piccoli. Studiate e diventerete qualcuno. Specializzatevi e farete successo. Quante volte ce lo siamo sentiti dire? E bene o male abbiamo sempre adottato questo approccio alla nostra vita lavorativa: tramite un corso formale di studi, universitario e successivo, oppure tramite corsi professionali e infine tramite auto-apprendimento.

Siamo degli esperti nel nostro settore, ne sappiamo più degli altri, più dei nostri collaboratori e dei nostri concorrenti, o almeno si spera. Non ci fermiamo mai: non è che finito il ciclo di studi abbiamo appoggiato i libri in biblioteca a prender polvere. Mai quanto vorremmo, ma cerchiamo di rimanere aggiornati: tramite corsi online o in aula, riviste di settore, blog specializzati, newsletter, webinar… le sorgenti di sapere sono tante, fin troppe se pensiamo al tempo che abbiamo.

Ma lo sappiamo: la concorrenza è in agguato e se non ci formiamo noi e rimaniamo al passo coi tempi, anzi davanti agli altri possibilmente, è un attimo rimanere indietro prima con il know-how e poi con le vendite. E di conseguenza, con la leadership o comunque la posizione di mercato. Quindi non mettiamo neanche in discussione di dover essere in continua formazione, in costante aggiornamento sulle tecnologie riguardanti il nostro specifico settore, qualunque esso sia.

E per le tecnologie che non sono sotto il nostro diretto controllo, che non fanno parte del nostro core-business, ci affidiamo ad esperti interno o esterni: un commercialista per gli aspetti fiscali, un avvocato per quelli legali, un’azienda di logistica esterna per i trasporti. E’ un approccio normale e corretto: la mia tecnologia, arte, servizio vero e proprio che vendo e che mi differenzia sul mercato lo curo personalmente come manager o imprenditore, o con un team specializzato. Tutto quello che non è strategico, lo delego a funzioni aziendali preposte o a società esterne specializzate.

Certo, un po’ ne voglio comunque capire. Per non farmi fregare. Per poter scegliere strategicamente. Per capire quello che mi viene offerto. Per contestare quando le cose non vanno. Giusto un po’, senza diventare specialista: gli esperti di tutte le competene non strategiche li assumo o li metto sotto contratto, ma intanto un po’ mi informo.

 

E il software? Scusa, che male ti ha fatto esattamente il software?

 

  • Pensi che il software si faccia da solo?
  • Che sia sufficiente “mio cuggino che ne sa di computer”?
  • Che il team di ingegneri meccanici, elettronici, hardware siano tutti comunque in grado di “sviluppare”?
  • Sei sicuro che in un’azienda di decine di persone, con team di progetto magari di 10-15 persone che curano tutti gli aspetti elettronici, meccanici, elettrici, prestazionali, estetici siano sufficienti 1-2 softwaristi “perché il software da sviluppare tanto è poco”?
  • Pensi che uno “smanettone”, come vengono chiamati i programmatori, si aggiorni da solo alle nuove tecnologie?
  • Pensi veramente che il ruolo crescente del software in termini di funzionalità non ne faccia anche crescere la criticità?
  • Ritieni inutile avere anche solo una conoscenza di base perché tanto ci sono gli esperti?

 

Se hai risposto un secco NO a tutte queste domande, forse questo blog non fa veramente per te. Ma se hai qualche dubbio… continua a leggere.

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