Ingegneria del software e metriche di prodotto software
Nell’ambito dell’ingegneria del software, se si vuole parlare di qualità di un software, bisogna riferirsi a determinati parametri e metriche che non sono cosi espliciti come in altri prodotti. Il problema infatti sta nel fatto che non si ha nulla di tangibile su cui basarsi e pertanto bisogna usare delle strategie per capire se il prodotto è di qualità o meno.
Come e quando possiamo dire che un software è di qualità? Quali sono gli aspetti che garantiscono la qualità?
Non si può dire in maniera univoca se un software è di qualità poiché esso va sempre contestualizzato e valutato in base al contesto in cui agisce. Bisogna verificare che il sistema soddisfi sempre i requisiti. Se ad esempio un software soddisfa i requisiti utente ma non quelli non funzionali no si può dire che esso sia un sistema di qualità. I requisiti non funzionali servono proprio a capire la qualità del sistema. E quindi il problema sta proprio nel valutare e considerare i requisiti non funzionali, ossia gli attributi di qualità. Essi determinano una specifica di qualità. Si può cercare di mettere ordine tra tutti i possibili attributi di qualità in modo da cpaire quali sono i più importanti che il sistema deve necessariamente rispettare per essere un sistema di qualità. Il problema sta nel mettere in relazione i requisiti non funzionali con il sistema stesso. Ad esempio, un requisito non funzionale può essere la sicurezza.
Ma come capisco dal sistema se il requisito è garantito o meno?
Il sistema ha una sua complessità, i requisiti sono parametri qualitativi e pertanto bisogna creare un rapporto tra questi due. Per fare ciò si utilizzano dei modelli di qualità e ne esistono diversi tipi.
Diamo però prima la definizione di requisito secondo RUP (Rational Unified Process ovvero una estensione del modello Unified Process UP):
“Un requisito descrive una condizione o una capacità a cui un sistema deve conformarsi; può essere sia derivato direttamente da esigenze degli utenti, o indicato in un contratto, uno standard, in delle specifiche o altri documenti o essere formalmente imposto.”
Detto ciò, bisogna anche dire che un requisito architetturale ha importanza nella valutazione dell’architettura software e nella sua implementazione. Essi possono essere sia impliciti (attributi di qualità) che espliciti (di natura tecnica).
Modello FURPS+ e Metriche di prodotto
Tra tutti i requisiti non funzionali impliciti, un valido tentativo di mettere ordine è dato dal modello FURPS+ (Funzionalità, Usabilità, Affidabilità, Prestazione, Supportabilità) dove il + rappresenta le diverse categorie di requisiti.
Dati i modelli di qualità ci poniamo l’obiettivo di valutare la qualità del sistema.
Come faccio? Per esempio con un modello orientato all’obiettivo. Cominciamo a definire le metriche e a vedere cosa sono. “Una metrica è una misura quantitativa del grado in cui un sistema possiede un determinato attributo”.
Un modello orientato all’obiettivo è il GQM, ossia un modello che a partire da dei GOAL da raggiungere e verificare, mediante opportune Question permette di individuare delle metriche che misurano uno o più parametri che permettono la soddisfazione di alcune specifiche di progetto.Costruisco poi un foglio detto foglio metrico, diviso in quattro parti che mi serve per organizzare la valutazione che sto facendo.
| Oggetto dello studio Scopo | Prospettiva Punti di Vista Contesto |
| Quality Focus | Variation Factors |
| descrive la relazione tra i fattori di variazione e le metriche del quality focus | contiene i quesiti e le metriche per la conformità del processo o della caratterizzazione del prodotto |
| Baselines Hypothesis | Impact on Baseline Hypothesis |
| contiene i quesiti e le metriche dei modelli di conferma e di validità | descrive la relazione tra i fattori di variazione e le metriche del quality focus |
Vediamo le metriche più diffuse e conosciute:
- Metriche per il modello analitico
- Metriche per il modello progettuale:
- Metriche dei punti funzione;
- Metriche CK;
- Metriche MOOD.
- Metriche di Laurence e Kid.
- Metriche per il codice sorgente (in questa categoria si hanno misure del tipo lunghezza del programma, linguaggio, volume).
