La qualità del software passa per i controlli e i controlli si possono fare esclusivamente confrontando i risultati con quelli di soluzioni note.

La qualità del software può essere influenzata dalla qualità dei modelli adottati (a esempio la qualità del modello numerico di un elemento finito), dalla qualità dell’algoritmo prescelto (a esempio come viene tradotta in singoli passi la formulazione matematica del modello) e dalla qualità della implementazione (traduzione in codice impiegabile della descrizione dell’algoritmo).

Un confronto con una soluzione nota consente di verificate tutti e tre queste fasi. Inoltre questo tipo di controllo può essere eseguiti usando i codici eseguibili e non è fatto, come altri controlli di produzione, sui codici sorgenti. Quindi è alla portata di tutti. Ma i controlli non devono essere fatti su casi-prova banali ma studiati appositamente per verificare i lati deboli del programma. I test, a esempio, di una vettura, non si fanno su una strada larga e in piano ma in condizioni limite. Così è per il software. Trovare condizioni limite non è facile ed è compito di esperti. Per questo qui riportiamo dei benchmark o “casi prova” di rilievo internazionale, altrimenti non facilmente reperibili per chi non è “addetto ai lavori”.

I motivi per cui si dovrebbero usare i casi prova sono molteplici.

Il primo sicuramente è didattico. I casi prova in genere sono complessi proprio per quanto abbiamo detto: devono “stressare” il programma, non farlo andare in discesa. Fare il modello corretto di un caso prova con il proprio programma è un buon esercizio. Una sfida più avvincente delle parole crociate, per chi è appassionato di enigmistica.

Poi sono uno strumento indispensabile per capire i limite dello strumento che si usa. Partire dalla assunzione che il software sia perfetto è illusorio. Con il software bisogna abbandonare atteggiamenti da “diritti dei consumatori” e capirne l’intrinseca natura che ha dei limiti connaturati. I benchmark aiutano a capirli per non avere sorprese.

Prima di comprare un programma o di usarlo, fare dei casi prova è sempre consigliabile se non indispensabile. Fare i modelli per eseguire i benchmark non è una perdita di tempo perché aiuta a capire il programma che si sta usando sottoponendolo a casi prova internazionali che non possono non essere agilmente modellati sul programma che si intende usare. Controllarne i risultati è una garanzia a vostro favore e per la vostra sicurezza. Ricordate che è vostra la responsabilità di usare strumenti adeguati. Non è detto che un software sia di cattiva qualità se non assolve a pieno ai vostri specifici compiti. Dovete accertarvene. La domanda: “Ma hai controllato prima?” vi può essere sempre fatta perché è vostro compito. Poter rispondere: “Sì, ho fatto il test tale e tal’altro”. Questo vi mette sopra ogni possibile critica.

Infine il software deve essere sottoposto a benchmark continui. Ogni nuovo rilascio deve esserlo perché i “bachi” non aspettano altro che uno scriva una sola riga di codice per intrufolarsi. I benchmark che qui riportiamo fanno parte dal sistema automatico di test dei nostri programmi, soprattutto di Nòlian e quindi sono anche una “finestra” sul nostro modo di produrre il software. Una garanzia in più di trasparenza per i nostri utenti.