Il potere del pensiero positivo nell’ambito dello sviluppo applicativo e di software può essere devastante; tale positivismo può farci diventare ciechi rispetto a gravi problemi che il software presenta e che non riusciamo a vedere, ma che certamente emergeranno nel futuro. Mostrare solo dati positivi, magari tralasciando quelli negativi valutandoli basandosi sulle classiche frasi che sentiamo pronunciare nelle varie riunioni come:
- “Credimi…”;
- “Questo non dovrebbe essere un problema…”;
- “Nella mia esperienza…”;
- “La nostra ricerca ci mostra che…”;
comporta rendere attivi confirmation bias ed ignorare aspetti che ci stanno segnalando che non stiamo facendo le cose correttamente. Anche gli armatori ed i timonieri del Titanic pensavano che la loro nave fosse inaffondabile ed ignorarono numerosi avvisi, tutti sappiamo come è andata a finire.
Lo scetticismo ed i Quality Attribute Requirements(QAR)
Ovviamente auspichiamo che non avvengano mai simili tragedie, ma questi tragici eventi ci devono far rendere conto che spesso occorre mettere da parte il positivismo a tutti i costi ed invece occorre introdurre un sano scetticismo. Scetticismo che non vuol dire negativismo ma semplicemente consapevolezza che qualcosa potrebbe andare storto e che, quindi, dobbiamo collezionare e valutare i dati e le informazioni che ci permettono di predire alcuni malfunzionamenti e/o problemi potendo, pertanto, realizzare le azioni necessarie per correggerli e/o mitigarli.
Scetticismo vuol dire investigare il codice sorgente, testarlo, stressarlo anche attraverso la creazione del caos; tutto questo perchè, quale che sia l’architettura che hai progettato, non puoi essere certo che tutto sia perfetto: gli utenti, i sistemi, gli hacker sono variabili che non puoi controllare direttamente ma puoi mitigare qualsiasi rischio attraverso l’introduzione dello scetticismo.
Renderlo concreto vuol dire progettare i software guardando non solamente ai requisiti funzionali ma anche e soprattutto ai Quality Attribute Requirements(QAR). I QAR rappresentano il valore che ha la funzionalità, valore inteso con logicità e buon senso. Facciamo un esempio: non è un QAR corretto affermare che “l’applicazione deve essere rapida” oppure che “l’applicazione deve essere scalabile” perchè sono affermazione troppo vaghe; nello stesso tempo non è un QAR corretto affermare che “la nuova applicazione deve processare i dati in maniera 10 volte più veloce della precedente” perchè non è realistico. Mentre è corretto un QAR che afferma che “l’applicazione deve fornire i dati rientrando in performance superiori al 90% dei Core Web Vitals“.
Il QAR indicato è reale, ha delle metriche, si può confrontare, è oggettivo ed ha un impatto concreto verso l’utente finale. Occorre inoltre definire i QAR in maniera formale per poter effettivamente garantire che quanto sviluppato corrisponda alla qualità che ci aspettiamo.
Scetticismo in pratica
Chiaramente non è sufficiente scrivere cosa vorremmo da un software per automaticamente ottenerlo ma invece occorre utilizzare strumenti tecnologici, oramai maturi, che mettono sotto stress la nostra applicazione, ne abbiamo parlato nel precedente articolo “Come garantire la qualità del software: code review, stress test, fuzzing ed analisi funzionale“.
A ciò bisogna aggiungere elementi del Behaviour Driven Development(BDD) come le User Story per poter orientare lo sviluppo del software verso il reale utilizzo e non le mere funzionalità.
Sottovalutare gli elementi indicati continuando a concentrarsi solo sulle funzionalità vuol dire affrontare con certezza problemi continui che, avendo una base architetturale errata, continueranno a permanere ed a peggiorare. I casi e gli esempi si sprecano e se hai un software utilizzato da migliaia di persone progettato e realizzato senza QAR, fuzzing, stress test e analisi funzionale probabilmente hai già affrontato numerosi problemi e li starai continuando ad affrontare. Contattaci subito e senza impegno per ristrutturare il tuo software.
Glue Labs e la qualità del software
Abbiamo realizzato applicazioni impiegate in ambito energetico, sanitario e gestionale. Gli ambienti critici in cui il nostro software opera ci hanno permesso di costruire un’importante sensibilità verso la qualità del software, sensibilità che ci permette di fornirti la tua applicazione con garanzia 12 mesi da qualsiasi bug. Grazie all’esperienza maturata in tantissimi settori, con numerosi Clienti e con un solido gruppo aziendale ti forniamo le competenze per progettare, sviluppare e manutenzionare anche in maniera evolutiva le tue applicazioni. Contattaci subito e senza impegno per maggiori informazioni.
