Obiettivi possibili delle metriche:
1) Provare a predirre la quantità di nuovi moduli o modifiche da sviluppare
2) Valutare lo sforzo impiegato per svilupparlo
E' da valutare prima di tutto quanto tempo si può impiegare nella misura delle metriche per non generare un overhead nella generazione di queste statistiche.
Predirre la quantità di nuovi moduli o modifiche da sviluppare
Predirre in base ai requisiti
Per il primo caso ci si può basare sui Punti Funzione.
Questo metodo è difficile da usare e può portare a valutazioni disparate a seconda delle interpretazioni dei requisiti, della variabilità dei requisiti stessi [4][5].
A parte il peso, comunque, la valutazione delle interfacce da costruire e la valutazione di tutti gli input e output da implementare può avere un valore ma deve essere considerata la volatilità dei requisiti che si vanno a implementare, per cui gli Unadjusted Function Points (UFP) possono risultare differenti a seconda della variabilità dei requisiti esposti.
Calcolo dei punti:
I punti vengono calcolati in base a interfacce interne (come tabelle di un proprio database), interfacce esterne (web services o interfacce gestite dal di fuori dei confini dell'applicazione - più comuni nelle nostre applicazioni) e tre tipi di processi che elenco di seguito:
EI - External Input: processo elementare di input di dati dall'esterno, ad esempio tramite un form o tramite un file xml esterno (come quelli di alfresco)
EO - External Output: processo elementare di output verso l'esterno (in genere verso l'utente) che necessitano di una logica più o meno complessa per la generazione dei dati
EQ - External Inquiry: come EO ma non necessita di logica nell'applicazione per il calcolo dei dati da mostrare. Questi vengono solo recuperati e dati all'esterno.
Gli UFP possono poi essere pesati in base a un indice VAF che ripende da varie considerazioni sul software che si sviluppa. Questo indice può variare considerevolmente il risultato dei punti funzione e spesso è criticato per la sua soggettività. I pesi da valutare sono fondamentali per la giusta pesatura e dipendono anche molto dalla esperienza del valutatore.
Più una metrica dipende dall'esperienza del valutatore, più non si può considerare una metrica ma una stima. [7]
Purtroppo la fonte principale [A] è una fonte chiusa, a pagamento, probabilmente anche per i corsi e certificazioni che propone.
Alcune considerazioni a prima vista
Le nostre interfacce interne sono poche. La maggior parte dei processi prendono dati da fonti esterni alle nostre applicazioni e non abbiamo nostri database.
In generale i punti funzione non valutano gli interventi non funzionali e il lavoro di alcuni può essere meno facilmente valutato tramite questo strumento (interventi sulla performance, sullo stile di visualizzazione, etc.)
Il processo è molto incentrato sugli output e gli input e la valutazione di processi Machine to Machine, processi schedulati e altri processi non funzionali devono essere valutati in modo speciale (ad esempio come output non verso l'utente).
Gli interventi di manutenzione (evolutiva o correttiva) possono essere valutati ma hanno un valore molto relativo. Per la misura di questo tipo di interventi si può valutare una funzione più ragionata come [9] ma risulta poi quantomeno difficile il confronto con i punti calcolati per nuove funzioni.
Valutare lo sforzo, le ore impiegate per sviluppare software
Per valutare il codice sviluppato si possono usare varie metriche.
Avendo la fortuna di lavorare con Eclipse ci si può avvalere di plugin come quello a [2] per calcolarle senza troppi sforzi.
Probabilmente la cosa migliore e più utile sarebbe pesare vari criteri per il calcolo dello sforzo totale (S):
1) Il numero di classi create e modificate ha un peso (CC)
2) La complessità del codice sviluppato (tramite ad esempio la complessità ciclomatica di McCabe) ha un peso (McC)
3) Le linee di codice vanno pesate in una valutazione (LOC)
4) Si deve quindi pesare in base al numero di punti funzione valutati (UFP)
es di funzione per un intervento:
Il risultato può essere pesato in base a dei feedback dovuti a parametri quali quelli che seguono.
A) Le ore dichiarate dalla persona come lavorate su un certo task possono essere valutate eventualmente per un confronto nel tempo col risultato ottenuto dalle metriche.
B) Allo stesso modo, il numero delle ore previste per la lavorazione di una certa funzione possono essere confrontate eventualmente nel tempo con i risultati delle metriche per la correzione delle previsioni stesse e per la valutazione delle metriche ottenute.
Nota: per una valutazione più giusta, bisognerebbe prendere in considerazione nel lavoro svolto, la mantenibilità del codice prodotto, in modo da favorire la tendenza verso un codice più mantenibile che garantisce meno lavoro la volta successiva. [3] Purtroppo gli strumenti che ho trovato per eclipse che calcolano l'indice di mantenibilità sono a pagamento.
Sarebbe auspicabile avere un modulo software che calcola quanto sopra in modo da non dover impiegare tempo nella valutazione ma il calcolo dei punti funzione probabilmente implica per forza una valutazione della persona in base ai requisiti e si può arrivare solo all'uso di un form da riempire online [6].
