Qualità del software
| Indice |
Caratteristiche
Si distinguono tra:
- Qualità esterne: percepibili dagli utenti
- Qualità interne: percepibili dagli sviluppatori
le seconde servono a raggiungere le prime.
Qualità esterne:
- Correttezza
- Affidabilità
- Robustezza
- Efficienza e Prestazioni
- Facilità d’uso
Qualità interne:
- Verificabilità
- Manutenibilità
- Riusabilità
- Portabilità
Qualità esterne
Correttezza
Un software è funzionalmente corretto se si comporta come stabilito nei suoi requisiti funzionali (functional requirements specification). Ciò presuppone l’esistenza di un documento di specifica dei requisiti. Va sottolineato che il termine requisiti funzionali si abbrevia nella forma requisiti, anche se abbiamo altri tipi di requisiti come quelli di prestazioni e di scalabilità.
Comunque deve essere possibile il confronto con i requisiti per verificare la correttezza. La specifica deve essere sufficientemente chiara e non ambigua, cosa abbastanza difficile perché sarà scritta in un linguaggio naturale e, per questo, ambigua.
Affidabilità
Misura quanto l’utente può far affidamento sul software.
È frequente oggi rilasciare software con malfunzionamenti per le prime versioni (software bacato). Ciò mostra chiaramente come il software sia ben lontano da altri prodotti ingegneristici perché un’auto, ad esempio, non si rilascia con dei malfunzionamenti, mentre se ciò avviene nel software questi sono accettati con rassegnazione.
Quindi per il software si hanno:
- aspettative minori
- known bugs (falle note)
Solitamente l’affidabilità è definita in termini di mtbf (Mean Time Between Failures).
Correttezza Vs affidabilità
La correttezza è una qualità assoluta, mentre l’affidabilità è una qualità relativa.
Se un sistema presenta degli errori
- non è corretto
- potrebbe essere però affidabile
Se la specifica cattura tutti i requisiti un sistema corretto è affidabile. Se la specifica non cattura i requisiti un sistema corretto potrebbe non essere affidabile.
Robustezza
Un sistema è robusto se si comporta in modo ragionevole in situazioni impreviste. Ad esempio quando vengono inseriti dati di input non corretti. La robustezza può essere corretta andando a colmare quelle lacune dei requisiti che appunto non hanno descritto il comportamento nel caso di situazioni anomale. La robustezza è difficilmente definibile formalmente. Se si potesse definire il concetto di comportamento ragionevole si potrebbe dire che la robustezza è uguale alla correttezza. Infatti se un requisito è nelle specifiche allora fa parte della correttezza, se è fuori allora fa parte della robustezza.
La robustezza comunque dipende dal contesto e non è assoluta, in particolare dipende da:
- chi usa il sistema
- quali sono le sue capacità di adattamento
- quanto è critico il buon funzionamento del software
Efficienza e Prestazioni
Un sistema è efficiente se usa le risorse (memoria, CPU,...) in modo efficiente, ossia senza sprechi. Si confonde spesso l’efficienza con le prestazioni, ma mentre la prima è una caratteristica interna che si riferisce al peso che un software ha sulle risorse del computer, la seconda è una caratteristica esterna, basata sui requisiti.
Spesso viene presa in considerazione solo a sistema realizzato, ma può essere molto difficile intervenire a posteriori.
Lo stesso accade anche per le prestazioni, che a volte possono anche rallentare la produttività, tuttavia esse sono relative perché possono cambiare con l’evoluzione della tecnologia. Esistono diversi modi per misurare queste qualità:
- complessità algoritmica
- misure sul campo delle caratteristiche (measurement)
- modello matematico da analizzare (analysis)
- modello di simulazione (simulation)
Usabilità
Un sistema è facile da usare se un essere umano lo reputa tale.
È una qualità soggettiva:
- dipende dal contesto
- dipende dall’esperienza
L’interfaccia utente interviene molto sull’amichevolezza di un’applicazione, ma anche in questo caso è la formazione e la cultura dell’utente a giudicare tale caratteristica.
Qualità interne
Verificabilità
Un sistema è verificabile se le sua proprietà:
- correttezza
- affidabilità
sono facili da verificare.
Per aumentare il grado di verificabilità si fa uso di:
- tecniche di progettazione modulare
- opportuni linguaggi di programmazione
- software monitor
In alcuni casi diventa una qualità esterna (Software safety critical)
Manutenibilità
Facilità di apportare modifiche a sistema realizzato. In origine si pensava che la manutenzione corrispondesse solo al bug fixing, ma oggi la situazione è più complessa infatti la manutenzione riguarda ogni miglioramento del software e andrebbe indicata più precisamente come evoluzione del software. Ormai 60% dei costi dipende proprio dalla manutenzione. Per analizzare questi costi occorre suddividere in manutenzione:
- Correttiva
- Adattativa
- Perfettiva
La manutenzione correttiva
- Elimina gli errori presenti sin dall’inizio
- Elimina gli errori introdotti da precedenti interventi di manutenzione
- Rappresenta il 20% del totale della manutenzione
La manutenzione adattativa:
- Modifiche a seguito di cambiamenti nell’ambiente
- Cambiamenti nell’Hardware, nel Sistema operativo, etc.
- 20% del totale
La manutenzione perfettiva
- Modifiche per migliorare le qualità del software
- Introduzione di nuove funzionalità
- Miglioramento delle funzionalità esistenti
- E’ la parte più consistente (circa il 60% del totale)
L’ultima parte è così consistente soprattutto per il legacy software che non può essere sostituito a meno di ingenti spese, per cui viene migliorato e adattato. La manutenibilità dipende da due aspetti
- Riparabilità per indicare ciò che consente di eliminare difetti
- Evolvibilità per indicare ciò che consente l’implementazione di nuovi requisiti
Riparabilità
Un sistema è riparabile se la correzione degli errori è poco faticosa. E’ una proprietà fondamentale di molti prodotti ingegneristici (automobili, computer,...). Per questi prodotti la tecnica usata è quella di abbassare il prezzo e di favorire la sostituzione piuttosto che la riparazione. Perché ciò possa avvenire si utilizzano delle parti standard che possono essere cambiate con facilità. Nel software la situazione è diversa.
- Non c’è usura (parti meccaniche);
- Non esistono componenti standard;
- Il costo non dipende dai pezzi ma solo dalla mano d’opera necessaria.
La riparabilità si persegue attraverso la modularizzazione. Non conta tanto il numero, ma piuttosto il come sono organizzati tra loro e al loro interno.
Evolvibilità
Il software, purtroppo, a differenza di altri prodotti ingegneristici è facilmente modificabile:
- Non si fanno mai studi di analisi di fattibilità approfonditi
- Non si progettano le modifiche
Peggio ancora, i cambiamenti effettuati non sempre sono documentati per cui le specifiche non vengono aggiornate e ciò rende i cambiamenti futuri difficili da compiere. E’ necessario prevedere sin dall’inizio che il software può evolvere e progettare tenendo in mente questa evoluzione per sfruttare al meglio i costi sostenuti in passato.
Riusabilità
Affine all’evolvibilità. Tuttavia si ha nell’evolvibilità una modifica per realizzare una nuova versione, mentre nella riusabilità si usano parti di sistema per realizzare un prodotto diverso. Inizialmente si pensava al riuso del software. Oggi si riusa tutto:
- Specifiche
- Progetti
- Testing
Indica il livello di maturazione della disciplina. Vantaggi:
- Diminuzione dei costi
- Aumento della affidabilità
Come fare per rendere i diversi manufatti riusabili?
- Tecniche di progettazione
- Tecniche di specifica
- Metodologie
- Standardizzazione del processo di sviluppo
Portabilità
Un sistema è portabile se è in grado di funzionare in ambienti diversi.
E’ diventato un aspetto fondamentale perché consente di avere vantaggi economici perché si possono ammortizzare i costi trasportando l’applicazione in diversi ambienti. Nel caso delle applicazioni web è la chiave di volta. Si usano strumenti e tecniche appositamente pensate per dare luogo ad oggetti portabili.