Qualità
Sono proprietà desiderabili del prodotto che costituiscono un “valore per le persone” (e quindi ), si dividono innanzitutto in due tipi:
- qualità esterne: qualità che vengono colte dai clienti;
- qualità interne: qualità che vengono esclusivamente colte dallo sviluppatore.
Le qualità interne non sono solo di interesse degli sviluppatori, ma influenzano spesso anche le qualità esterne (per esempio se ho un codice facimente verificabile, è più facile che il mio software risulti anche corretto).
Prima di vedere quali siano alcune proprietà auspicabili in un software, però, facciamo un’importante distinzione a livello terminologico tra requisiti e specifiche:
- I requisiti esprimono quello che il cliente vuole che il software faccia. Hanno la caratteristica di essere mutevoli, volatili. Sono cioè spesso cambiati in corso d’opera: il cliente cambia idea, priorità mano a mano che vede il progetto crescere. Alcuni modelli di vita del software moderni sono nati proprio per fronteggiare questa mutabilità.
- Le specifiche sono ciò che è stato capito dal programmatore a partire dai requisiti: si tratta di una definizione spesso più rigorosa di che cosa dovrà fare il software e in ogni caso scritta in un qualche linguaggio. Possono essere usati come base contrattuale tra cliente e sviluppatore. Chiaramente che se si parte da requisiti incompleti o non corretti anche le specifiche risulteranno inesatte (vd. G1).
Fatta questa doverosa distinzione, vediamo quali sono alcune delle qualità che un software dovrebbe idealmente possedere.
Qualità del software
Un software di qualità deve funzionare, essere bello e “farmi diventare ricco”.
| Un software deve... | Qualità | Descrizione |
|---|---|---|
| Funzionare | Correttezza | Un software è corretto se fa ciò che è scritto nelle specifiche. Più queste specifiche sono scritte formalmente e più (almeno dal punto di vista teorico) dovrebbe essere facile dimostrarne il rispetto da parte del software. |
| Affidabilità | Un software è affidabile quando ci si può fidare del suo funzionamento, ovvero ci si può aspettare che faccia ciò che si vuole. Qui il termine di confronto non sono le specifiche ma i requisiti stessi. Il controllo dell'affidabilità è compito del cliente (unico depositario dei requisiti) che a differenza del caso della correttezza potrà anche valutarne il soddisfacimento in maniera relativa/parziale/statistica: un software può essere affidabile (o dependable) anche se non corretto. Ad es. un programma che dà un valore che si scosta dal valore corretto entro un range di tolleranza (fissato non contrattualmente [cosa che lo farebbe diventare parte delle specifiche] ma stabilito unilateralmente dal cliente); oppure al limite anche un programma che crasha con una frequenza giudicata (sempre dal cliente) accettabile. | |
| Robustezza e/o Safety | Un software è robusto se si comporta in modo accettabile (nel caso della safety, senza generare effetti negativi) anche in circostanze non previste dalle specifiche. | |
| Essere bello | Usabilità | Un software è usabile (o user-friendly) se i suoi utenti lo ritengono facile e intuitivo da utilizzare. Si possono fare degli esperimenti (le grandi aziende lo fanno) per testare e quantificare l’usabilità del software ponendolo di fronte a dei soggetti umani (vd. NN23). Questa qualità è costosa a causa del grande numero di risorse da impiegare per garantirla, infatti sono necessarie sia delle analisi sia qualitative che quantitative. Le analisi qualitative vengono svolte facendo testare il software ad un gruppo di persone e analizzandone i feedback (verbale, o implicito tipo eye-tracking), mentre le analisi quantitative riguardano tutte quelle situazioni analizzabili tramite dei numeri (ad esempio numero di click necessari per fare una certa operazione, e se questa quantità è eccessiva oppure no). |
| Prestazioni e Efficienza | Ad ogni software è richiesto un certo livello di prestazioni. L'efficienza è una qualità interna e misura come il software utilizza le risorse del computer; la performance, d'altro canto, è invece una qualità esterna ed è basata sui requisiti dell'utente. Essa ha effetto sull'usabilità, e spesso viene considerata alla fine dello sviluppo software visto che vari avanzamenti tecnologici possono rendere efficienti algoritmi e processi prima troppo costosi. Questo però in maniera relativa perché un avanzamento tecnologico non permette la diminuzione della complessità di un algoritmo (se un algoritmo lavora in tempo esponenziale, un miglioramento hardware non causerà un'alterazione in positivo della complessità). | |
| Verificabilità | Un software è verificabile se le sue proprietà sono verificabili facilmente: è importante essere in grado di poter dimostrare la correttezza e la performance di un programma. Spesso è in tal senso correlata alla leggibilità del codice ma può essere ottenuta anche tramite metodi formali e strumenti di analisi appositi. È considerata una qualità interna, ma alcune volte può diventare una qualità esterna: per esempio, in ambiti in cui la sicurezza è critica il cliente può chiedere la certificazione di certe proprietà. | |
| Farmi diventare ricco | Riusabilità | Le componenti del software che costruiamo dovrebbero essere il più riutilizzabili possibile così da risparmiare tempo in futuro: per farlo bisogna aumentare l'adattabilità, ciò può essere fatto evitando di legare troppo il software allo specifico contesto applicativo. È possibile avere anche un aumento dell'affidabilità e della verificabilità, perché il codice riutilizzato è stato già testato e verificato al momento della sua creazione e soprattutto durante il suo periodo si uso. Con la proprietà di riusabilità, utilizziamo un prodotto (o più spesso un componente) per costruirne - anche con modifiche minori - un altro, anche se non sempre è un'operazione sicura a causa dei contesti diversi in cui il software può essere utilizzato (es: architettura hardware sottostante) (vd. MI15). Attenzione che come sempre deve essere adottato in maniera corretta. Ad esempio si cita spesso il fallimento del viaggio inaugurale (esplosione) del razzo Ariane 5, causato dal riuso di un componente software ereditato dall'Ariane 4 ma senza averne controllato correttamente le condizioni di uso assunte nel vecchio progetto. |
| Manutenibilità |
Per manutenzione software si intendono tutte le operazioni sul progetto svolte dopo il rilascio.
Questa proprietà può essere vista come due proprietà separate:
|
|
| Perfettibilità | Migliorare le qualità del software in modo da aumentare la qualità sia degli aspetti esterni che di quelli interni, senza però alterare le funzionalità richieste dalle specifiche. Questo aspetto quindi non va ad aggiungere o rimuovere features. |
Leggi rilevanti
Le imprecisioni/fraintendimenti/errori dei requisiti sono la prima causa del fallimento dei progetti.
Legge di Nielsen-Norman (NN23).
L’usabilità è misurabile.
Riutilizzare il software permette di incrementare la produttività e la qualità.
Un sistema che viene utilizzato cambierà.
Un sistema che evolve incrementa la sua complessità a meno che non si lavori appositamente per ridurla.
Debito tecnico
Durante lo sviluppo di un software è facile che pur avendo notato dei problemi nel codice si scelga di rimandarne la soluzione a un momento futuro. Questo modo di operare viene spesso chiamato “accendere un debito tecnico”, cioè ci si indebita sulla valuta “tempo di sviluppo”… Come per i debiti finanziari si deve essere coscienti che alla fine non si pagherà però solo con il tempo di sviluppo per sanare il problema, ma si saranno aggiunti gli interessi che in questo caso corrispondono a tutte le maggiorazioni di tempo che ci sono state durante lo sviluppo delle altre funzionalità causate dalla maggiore difficoltà di lavorare su del “brutto” codice.
Qualità del processo
È generalmente condiviso che le qualità del prodotto sono influenzate dalla bontà del processo che viene utilizzato per svilupparlo, di conseguenza diventa importante ragoinare e parlare anche di qualità del processo.
Anche un processo deve funzionare, essere bello e farmi diventare ricco, ma dobbiamo interpretare queste parole in maniera differente.
Quali caratteristiche ha un processo di qualità?
| Un processo deve... | Qualità | Descrizione |
|---|---|---|
| Funzionare | Robustezza | Un processo deve poter resistere agli imprevisti, come la mancanza improvvisa di personale o il cambiamento delle specifiche. Esistono certificazioni (CMM: Capability Maturity Model) che valutano la robustezza di alcuni processi aziendali e che vengono per esempio considerate nei bandi pubblici. |
| Essere bello | Produttività | La produttività di un team è molto meno della somma della produttività individuale dei suoi componenti. È una metrica difficile da misurare: conteggi come il numero di linee codice scritte o la quantità di tempo-uomo richiesta per un lavoro si rivelano spesso un po' fallaci. |
| Farmi diventare ricco | Tempismo |
|