WEBINAR 2019: registrazioni disponibili

Dopo il successo del 2019, ecco le registrazioni dei webinar effettuati:

07-28 Marzo: Requisito Perfetto (da cui il video-corso) 

21 Maggio: Verifica e Validazione del Software Automotive con ISO-26262 
 
 

04 Luglio: Presentazione Metodo M.E.D.S. 25 Luglio: Il grande inganno del Test Software

19 Dicembre: Modellazione e Simulazione dei Requisiti Software

Sappi che ho voluto pianificare altri 5 incontri per la prima metà del 2020, dedicati ad approfondire gli argomenti da voi più richiesti.

DI SEGUITO, LE DATE DEI PROSSIMI WEBINAR:

  • 16/01: Metriche KPI
  • 20/02: Focus Positioning per aziende Software
  • 19/03: Team Management Cultura Aziendale
  • 16/04: Strategie Avanzate di Testing Continuous Integration
  • 25/06: Approfondimento su Requisito Perfetto

A CHI SONO RIVOLTI I MIEI WEBINAR?    


– IMPRENDITORI che hanno a che fare con il software, direttamente o all’interno dei prodotti che creano

– MANAGER che gestiscono un gruppo di lavoro che scrive o integra del software

– TECNICI che vogliono imparare delle metodologie avanzate che migliorano la qualità e velocizzano il lavoro di scrittura del software

TI ASPETTO AI PROSSIMI INCONTRI!  

Registrati al canale YouTube di SOFTWARE SICURO per guardare gli altri video:

Canale YouTube SOFTWARE SICURO

Clicca invece qui per conoscere meglio CHI SONO IO E QUALI SONO I MIEI PROGETTI RICONOSCIUTI SIA A LIVELLO NAZIONALE SIA INTERNAZIONALE!
Per ogni tuo dubbio, perplessità e curiosità, scrivi pure a:
assistenza@softwaresicuro.it
Massimo

I 10 Comandamenti del Requisito Perfetto


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

An image

I 10 peggiori errori nel software che devi assolutamente evitare

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: 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

ROBERTO BAGGIO può insegnarti a vendere meglio il tuo software?

O IL DILEMMA DEL CALCIO DI RIGORE

Cos’hanno in comune Roberto Baggio, soprattutto quando ha dovuto calciare un tiro di rigore fondamentale per il Campionato Mondiale ed i miei clienti quando propongo loro una reale, efficace, collaudata strategia per risolvere veramente i loro problemi tecnologici?

Cosa c’è in comune tra un calcio di rigore e la scelta di un metodo, di un tool, di un processo aziendale? E perché certi errori come quelli del Mondiale del 94 ti ossessionano tutta la vita?

Si tratta di un fenomeno psicologico che capita nel mondo tecnologico ma che si può applicare a tantissimi altri ambiti.

Rappresenta lo stato di indecisione protratta e di mancata azione anche in caso i vantaggi di una scelta siano evidenti, concreti e reali

Nel mio caso sono aziende anche multinazionali, che di fronte a tecnologie innovative anche se provate e sicure che potrebbero far salvare soldi, tempo se non addirittura vite umane, preferiscono tentennare, aspettare, rimandare.

Anche se perdi tutto il tempo che vuoi e gli prospetti, mostrandogli tutti i vantaggi di questo mondo, loro rimarranno sempre dalla parte del NON FARE. Del RIMANDARE. Del MANTENERE LO STATUS QUO

 

Il 90% decide comunque di… NON decidere e di continuare così come prima, anche di fronte a vantaggi evidenti e misurabili.

 

 Perché? E’ una cosa che ha tanti nomi, a me piace chiamarla:

 

 PARADOSSO O DILEMMA DEL CALCIO DI RIGORE

 

Non ricordo i dati statistici esatti ma la domanda di base è: come si fa a calciare con successo un calcio di rigore assolutamente fondamentale, diciamo il rigore della vita? Magari ai Mondiali?

Bene, un calciatore metodico che si mettesse con approccio scientifico basato su calcolo delle probabilità, teoria dei giochi etc. si potrebbe guardare tutte le statistiche e scoprirebbe che diciamo il 43% dei portieri si butta a sinistra, ed il 47% si butta a destra (magari le statistiche cambiano di qualche punto percentuale ma la proporzione è questa).

A questo punto qual è la migliore strategia?

TIRARE AL CENTRO!

 

Infatti c’è solo il 10% di possibilità che il portiere te lo pari… 9 volte su 10 faresti goal… sarebbe la strategia (quasi) perfetta. Certo, c’è sempre qualcosa che può andare male… il portiere può capirlo e rimanere fermo, potresti tirare alto, beccare la traversa… vi ricorda forse qualcosa a voi italiani?

Bene, ora senza andare a ripescare una lunga serie di partite ed episodi famosi, perché quasi nessun calciatore tira al centro? Neanche se un coach gli spiegasse che è il metodo più certo? Che gli potrebbe garantire una probabilità altissima di successo (tranne che al povero Roberto Baggio)?

C’è un motivo psicologico, che è lo stesso identico per un publican, ristoratore, manager di un’azienda che si chiama semplicemente

 

PAURA DI SBAGLIARE

 

Se nella gara della vita, i Mondiali del 94 ad esempio, davanti ad un miliardo di persone in mondovisione, invece di fare il tuo dovere minimo e fare un tiro “normale” a destra o a sinistra, tu calci al centro e il portiere te la para, o la tiri alta… un miliardo di persone ti prenderanno in giro per tutta la vita e ti considereranno un fallito. Per sempre. Bollo di infamia.

Fa niente che la possibilità a secco fosse stata 1/10 di sbagliare e 9/10 di fare goal, la psiche umana è fatta in modo da non calcolare veramente le possibilità di una scelta e di procedere per istinto, non prende decisioni razionali se non a fatti avvenuti. Così come non compriamo un antifurto o un’assicurazione infortuni finché non rubano a noi o al vicino.

Quindi non è paura di sbagliare in toto:

è paura di intraprendere una strada nuova ed essere infamati solo e soprattutto per quello!

Perché Baggio avesse fatto un tiro normale, a destra o a sinistra, magari con effetto e avesse sbagliato… nessuno avrebbe detto niente, o quasi. Era il suo dovere quello di provare uno dei due lati, destro o sinistro, così come era dovere del portiere provare a pararla. Se vinceva il portiere… amen.

Invece così… hai voluto fare il furbo? Hai tirato al centro che è una soluzione apparentemente banale, ma efficace, che nessun fa? E perché hai fatto diverso dagli altri? Se non lo fa nessuno, perché ci hai provato tu? Così pensa la gente e non c’è (quasi) nulla che possa fare per fargli cambiare idea, soprattutto quando è troppo tardi.

Stessa cosa un Manager: sia che vada bene o male con la tecnologia attuale, con i tool acquistati in passato, con le metodologie applicate finora, perché mai dovrebbe prendere e mettersi a buttare tutta la sua sicurezza (o insicurezza) all’aria per l’ignoto di qualcosa di nuovo, innovativo e ragionevolmente sicuro?

Sarà una tecnologia buona, sarà di successo, sarà in crescita ma… amen. Chi deve prendere la decisione nuova, innovativa, dirompente piuttosto dice: per ora sto qua alla finestra ad aspettare. Perché se ho successo bene… ma se sbaglio e questa tecnologia fa schifo e i numeri, il fatturato, le metriche non migliorano, avrò un esercito di persone che mi rimprovereranno a vita: i capi, i colleghi, i soci, i dipendenti, le banche, i miei familiari se perdo lavoro.

“TE L’AVEVAMO DETTO!”

“COSA TI SEI ANDATO AD INVENTARE?”

“AVEVAMO IL NOSTRO MODO DI LAVORARE, PERCHÉ’ L’ABBIAMO ABBANDONATO?”

“CON IL VECCHIO MODO DI LAVORARE SAPEVAMO I PROBLEMI A CUI ANDAVAMO INCONTRO”

 

Queste parole, così come i fischi del pubblico, sono quelle che ti risuonano nella mente prima di ancora di fare qualunque passo: e se succede veramente questo, se un tuo cliente ha paura di sbagliare, di innovare, di essere dirompente, allora non c’è attività di vendita, non c’è tentativo di spingere, di piazzare una cosa innovativa nella mente di uno che la pensa così e che non cambierà MAI idea, se non quando è troppo tardi o quando una buona parte dei concorrenti ha adottato questa tecnologia ma oramai è tardi per averne un vantaggio competitivo.

 

Il tuo cliente non te lo dice ma pensa:

e se faccio la fine di Roberto Baggio? Deriso per sempre?

 

Fa niente che da un punto di vista statistico, logico, scientifico avesse ragione. Non è passato alla storia per aver rischiato, osato, sfidato il portiere con una tecnica incredibile: è passato alla storia per un errore banale. E di questo ha paura il TUO cliente.

Ed è per quello che la TUA strategia deve essere completamente diversa… e coordinata. Devi fornire prove, evidenze, misure, metriche, KPI prima. Devi fornire testimonianze, referral, casi di studio reali. E spesso non basta: devi offrire anche prove gratuite, valutazioni, proof-of-concept. E via discorrendo. Altrimenti nessuno ti crederà sulla parola, neanche quando i vantaggi sembrano immediati, reali, visibili. C’è sempre questa maledetta paura di sbagliare, di prendere la via nuova per la vecchia.

Capisci ora perché serve un METODO che ti aiuti, ti guidi, ti consigli non solo nello sviluppare il tuo prodotto, nel renderlo il migliore, il più moderno, efficiente, avanzato se poi una volta che è sul mercato la gente non te lo compra perché non sai dimostrare PRIMA che non farai fare brutta figura? Che non li farai fallire davanti alla propria azienda?

E quindi tutto il tuo ciclo di sviluppo, oltre ad essere efficiente, veloce, ottimizzato per tagliare costi, rischi e tempi, dovrà essere concepito anche per poter misurare, quantificare, evidenziare i vantaggi, verificarne le performance, farlo provare ai tuoi futuri clienti, ricevere feedback dal campo, testimonianze dai primi utilizzatori. Questo ed altro ancora è l’obiettivo di questa serie di articoli e del mio futuro libro… dove affronterò questi ed altri temi.

per avere un’anteprima dei primi capitoli del mio libro non appena saranno pronti.

Per cui come sempre: stay tuned!

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

Sicurezza di prodotto o di processo?

Se passi davanti a un negozio IKEA, può capitare di trovare questo strano dispositivo:


 

È una scatola di plexiglas trasparente, contenente una poltrona IKEA, uno strano braccio robotico con due grandi pistoni che spingono la sedia e un contatore. È una specie di esperimento di simulazione di una persona di 80 kg. seduto e in piedi, ripetuto per migliaia e migliaia di volte.

Probabilmente hai guardato il bancone, hai visto un numero come 999.999-1.000.000- … e hai fatto un po’ di matematica mentale

“Probabilmente io e la mia famiglia potremmo sederci e alzarci in media 10 volte al giorno, 3.650 totali all’anno … quindi questo la sedia durerà almeno 300 anni “

E con la giusta fiducia nella sua robustezza, hai deciso di comprarla.

Ora pensiamo a un software critico per la sicurezza: ti potrebbe essere richiesto di certificare secondo il severo standard DO-178C, fino al livello A. Bene, guardando questa o altre normative di sicurezza correlate, potresti trovare che associato al livello A, hai una probabilità di errore 10E-9 ore di volo. Ok, ancora matematica… significa:

1 miliardo di ore senza problemi, o meglio 11.574 anni

Undicimila anni! Sembra abbastanza buono, non è vero? Tranne il fatto che… per il software, in realtà non funziona così. Cosa significa veramente DAL-A? Letteralmente, significa Design Assurance Level: garanzia del DESIGN.

Ma la vera probabilità di un guasto del software è molto più alta … alcuni esperti dicono che la probabilità è 1 ovvero il 100%! Potresti essere abbastanza sicuro che il tuo software fallirà! Pensa al tuo sistema operativo desktop o mobile … puoi immaginare un’app per il tuo smartphone o computer che resista migliaia di anni senza crash o bug?

E pensi che il software avionico possa essere reso così solido per millenni? Possa davvero essere rilasciato fin dall’inizio totalmente senza bug?

NON E’ COSI’

ed ora ti spiego perché.

Read More

5° Comandamento Software: NON UCCIDERE

Il software è uno dei prodotti più complessi mai prodotti dall’uomo, senza paragoni. Non esiste prodotto letterario, programma scientifico, opera architettonica che possa eguagliare il numero di ore/uomo o anni/uomo necessari a produrre un software di grande complessità come quello che equipaggia un moderno aereo, un’automobile di ultima generazione, il computer o smartphone che state utilizzando, un social come Facebook.

Ed il software è talmente complesso che spesso sbaglia… anzi, uccide.

 

Il software uccide le persone, brucia capitali enormi, fa saltare in aria le aziende, crea irreparabili danni di immagine

 

Nel 1982, si sospetta che la CIA abbia volutamente introdotto un bug (errore software) all’interno del codice di controllo della condotta di gas transiberiana in Russia. Per motivi di contro-spionaggio, gli USA hanno deciso di far esplodere tale condotta una volta operativa con il risultato di provocare la più grande esplosione non-nucleare della storia.

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