Nell'ambito informatico, la ricerca del miglior metodo per misurare un software è sempre stato uno degli aspetti più discussi e discutibili.
Esiste una metodologia strutturata per calcolare il peso ed il valore di un'applicazione software ?
Quali sono le metriche più adatte per valutarne le difficoltà, le competenze e l'impegno necessario per l'implementazione ?
Come si fa a stimare un progetto informatico prima della realizzazione per poterlo quotare economicamente ?
Conteggio delle linee di codice e delle istruzioni
Fino alla fine degli anni 80 si usava contare le linee di codice oppure il numero degli statement, tipicamente dei punti e virgola, che identificano il termine di ciascuna istruzione nei programmi procedurali e strutturati.
Questi due metodi però, oltre ad essere utilizzabili solo a sviluppo terminato e quindi non per una stima preventiva, risentono pesantemente dallo stile e dal linguaggio di programmazione.
Conteggio delle classi e delle interfacce
In seguito, con l'introduzione della programmazione object oriented, si è passati a misurare le applicazioni conteggiando classi, metodi ed interfacce.Anche in questo caso però il limite principale rimane la soggettività rispetto a quanto fa lo sviluppatore, alle tecniche di programmazione ed alle librerie di terze parti utilizzate e non conteggiabili.
Stima in giorni/uomo
Per le stime preventive, la metrica più utilizzata è quella in giorni/uomo: il fornitore basandosi su determinati parametri (requisiti espressi, competenza, esperienza, tecnologie utilizzate, ecc.), valuta e comunica al cliente quante giornate di lavoro cumulative (Effort) servono per realizzare il prodotto.
Al fine di ottenere la valutazione economica viene condivisa una tariffa giornaliera che, moltiplicata per l'effort stimato, determina il valore del progetto.
L'effort è sempre opportuno esprimerlo separatamente per le diverse figure professionali coinvolte nel progetto, in modo da poter poi applicare tariffe differenti in base al costo di ciascuna ed arrivare quindi ad una stima più precisa.
Al fine di ottenere la valutazione economica viene condivisa una tariffa giornaliera che, moltiplicata per l'effort stimato, determina il valore del progetto.
L'effort è sempre opportuno esprimerlo separatamente per le diverse figure professionali coinvolte nel progetto, in modo da poter poi applicare tariffe differenti in base al costo di ciascuna ed arrivare quindi ad una stima più precisa.
Questo, che probabilmente è il metodo migliore in quanto mette direttamente in relazione il software con il lavoro/tempo che serve per realizzarlo, presuppone però una grande competenza ed esperienza in progetti analoghi, sia da parte del fornitore che fa la stima, sia del cliente che deve valutarne la correttezza.
Abbiamo parlato dell' Effort, per completare il quadro di seguito una descrizione sintetica dei termini che vengono utilizzati nella valutazione e pianificazione temporale di un progetto:
- Effort (Sforzo, Impegno): è il numero di unità di lavoro temporali (es. giorni/uomo ma potrebbero essere anche ore o settimane) richieste per completare l'attività. Per determinare la durata dell'attività, l'effort deve essere stimato prima;
- Duration (Durata): è il tempo totale che serve per completare l'attività in base alle risorse umane disponibili. La durata, che non include vacanze e giorni non lavorativi, può essere espressa in giorni, settimane o mesi;
- Elapsed (Tempo trascorso): è il tempo di calendario o intervallo necessario per completare le attività in base alle risorse disponibili includendo però anche i giorni festivi e non lavorativi. Anche l'elapsed può essere espresso in giorni, settimane o mesi
Esempio:
La stima per un nuovo progetto software prevede un Effort di 10 giorni/uomo.
Con una persona sola che lavora 5 giorni a settimana dal lunedì al venerdì, la Duration è di 10 giorni lavorativi con un Elapsed di 2 settimane
Se invece ci lavorano 2 persone, la Duration è 5 giorni lavorativi con un Elapsed di 1 settimana.
Conteggio dei Function Point
Per definizione, il conteggio in Function Point (FP) esprime la dimensione funzionale di un prodotto software.
Tale metodologia, sviluppata nel corso degli anni dal IFPUG (International Function Point Users Group), può essere utilizzata prima o dopo la realizzazione del software perchè viene applicata alla specifiche funzionali e non alla implementazione della applicazione stessa.
In altre parole l'obiettivo è quello di misurare le funzionalità, indipendentemente dalla tecnologia utilizzata, dalle modalità di realizzazione e dalle problematiche di contesto.
Tale metodologia, sviluppata nel corso degli anni dal IFPUG (International Function Point Users Group), può essere utilizzata prima o dopo la realizzazione del software perchè viene applicata alla specifiche funzionali e non alla implementazione della applicazione stessa.
In altre parole l'obiettivo è quello di misurare le funzionalità, indipendentemente dalla tecnologia utilizzata, dalle modalità di realizzazione e dalle problematiche di contesto.
Il conteggio dei FP non è una operazione proprio facilissima ed intuitiva, lo testimonia anche il fatto che l'esame per diventare un IFPUG Certified Member è abbastanza complesso (niente di impossibile beninteso) in quanto le regole e le nozioni sono parecchie e di non immediata digeribilità.
Senza entrare nel dettaglio, la misurazione prevede l'identificazione ed il conteggio dei movimenti dati (dati di input e output dell'applicazione) e degli archivi logici memorizzati e raggiunti dall'applicazione.
Le elaborazioni applicative vengono classificate come Inferenze o Regole, escludendo ogni valutazione riguardo alle performance, alla complessità, ai meccanismi tecnologici e di programmazione.
Per questo motivo la dimensione funzionale espressa in FP rappresenta solo uno degli aspetti di misura di un software, non include infatti la copertura dei requisiti di qualità, sicurezza, velocità, robustezza, gestibilità, scalabilità, tecnici e di contesto per i quali bisogna utilizzare altri metodi di valutazione.
Per poter convertire una misurazione funzionale in una stima economica, è necessario stabilire a priori quanto vale un Function Point oppure qual'è il rapporto di conversione tra FP e giorni/uomo ( quanti FP riesce ad implementare un uomo in un giorno?), parametri entrambi aleatori e molto variabili in base al contesto ed alla contrattazione commerciale tra cliente e fornitore.
Ne consegue che tale metodologia, molto utile ad esempio per una comparazione funzionale tra diversi software o per la valutazione delle attività di manutenzione evolutiva rispetto al progetto iniziale, risulti insufficiente o addirittura fuorviante per effettuare stime economiche corrette.
Se non applicata in modo adeguato ed accompagnata anche da altri razionali di valutazione, a parere di molti questa metodologia introduce solo un ulteriore significativo impegno per il cliente ed il fornitore, protagonisti di lunghissimi confronti sui conteggi effettuati, costretti successivamente a dover riconvertire tutto in giorni/uomo, per poi probabilmente scoprire che la stima ottenuta non è assolutamente commisurata al lavoro da svolgere.
Senza entrare nel dettaglio, la misurazione prevede l'identificazione ed il conteggio dei movimenti dati (dati di input e output dell'applicazione) e degli archivi logici memorizzati e raggiunti dall'applicazione.
Le elaborazioni applicative vengono classificate come Inferenze o Regole, escludendo ogni valutazione riguardo alle performance, alla complessità, ai meccanismi tecnologici e di programmazione.
Per questo motivo la dimensione funzionale espressa in FP rappresenta solo uno degli aspetti di misura di un software, non include infatti la copertura dei requisiti di qualità, sicurezza, velocità, robustezza, gestibilità, scalabilità, tecnici e di contesto per i quali bisogna utilizzare altri metodi di valutazione.
Per poter convertire una misurazione funzionale in una stima economica, è necessario stabilire a priori quanto vale un Function Point oppure qual'è il rapporto di conversione tra FP e giorni/uomo ( quanti FP riesce ad implementare un uomo in un giorno?), parametri entrambi aleatori e molto variabili in base al contesto ed alla contrattazione commerciale tra cliente e fornitore.
Ne consegue che tale metodologia, molto utile ad esempio per una comparazione funzionale tra diversi software o per la valutazione delle attività di manutenzione evolutiva rispetto al progetto iniziale, risulti insufficiente o addirittura fuorviante per effettuare stime economiche corrette.
Se non applicata in modo adeguato ed accompagnata anche da altri razionali di valutazione, a parere di molti questa metodologia introduce solo un ulteriore significativo impegno per il cliente ed il fornitore, protagonisti di lunghissimi confronti sui conteggi effettuati, costretti successivamente a dover riconvertire tutto in giorni/uomo, per poi probabilmente scoprire che la stima ottenuta non è assolutamente commisurata al lavoro da svolgere.
 |
| Image courtesy of Stuart Miles at FreeDigitalPhotos.net |
