Metodi di misurazione delle dimensioni funzionali

Questa è la seconda parte del blog incentrata su una serie di popolari metodi di misurazione delle dimensioni del software e sulla loro utilità per la stima del progetto software. In questa seconda parte i metodi di misurazione delle dimensioni funzionali IFPUG, NESMA e COSMIC sono coperti. Nei blog futuri tratterò metodi di misurazione delle dimensioni non funzionali e metodi ibridi.

Si consiglia vivamente ai lettori interessati a questo argomento di leggere prima il prima parte di questo blog, prima di leggere questa seconda parte.

Affinché un particolare metodo di misurazione delle dimensioni del software sia utile per la stima del progetto software, dovrebbero valere le seguenti caratteristiche:

• Il metodo di misurazione delle dimensioni può essere eseguito in un obiettivo (indipendente dalla persona che lo fa), ripetibile, verificabile e quindi difendibile modo;
• La dimensione in sé è utile solo quando dati storici è disponibile di progetti misurati in tale metodo di misurazione delle dimensioni;
• I metodi di misurazione delle dimensioni dovrebbero essere supportati da modelli e/o strumenti parametrici al fine di tener conto con precisione delle caratteristiche specifiche del progetto che influenzano la stima, come per esempio COCOMO II, SOTTILE, SEER per software o Vera pianificazione.

Ovviamente, qualsiasi metodo di misurazione delle dimensioni del software che non soddisfa uno o più di questi criteri può comunque essere molto utile per un'organizzazione, a condizione che elaborino una procedura che garantisca la ripetibilità delle misurazioni dimensionali, raccogliere e analizzare dati storici e/o costruire propri modelli di stima sulla base dei dati raccolti. Per questo blog invece, l'attenzione si concentra sull'utilità teorica del metodo di misurazione specifico per scopi di stima del progetto software nel contesto di organizzazioni che non dispongono ancora di un processo di stima parametrica in atto. Per queste organizzazioni, che sono disposti a implementare un metodo di misurazione delle dimensioni per stimare i progetti software, questo blog può servire come linea guida per selezionare un metodo specifico.

Incoraggio tutti a inviare commenti e/o feedback su questo blog.

Nesma FPA

Nesma FPA è molto simile a IFPUG in quanto misura gli stessi componenti funzionali di base (BFC [24]) (ILF, FEI, NO, È IL, EQ) e ora ci sono pochissime differenze tra le linee guida di conteggio dei due metodi. Molti esperti usano la dimensione misurata in punti funzione IFPUG uguale alla dimensione in Nesma FP. I principali vantaggi di Nesma rispetto a IFPUG ai fini della stima è la disponibilità di una serie di metodi derivati ​​che sono considerati parte dello standard ISO/IEC:

• FPA indicativo: questo metodo può essere utilizzato molto presto nel ciclo di vita del progetto quando viene specificato solo il modello di dati. La precisione non è molto alta (-30% / +50%), ma di solito abbastanza da essere utile in una fase iniziale del ciclo di vita del progetto quando è necessaria solo una stima del ROM.
• FPA di alto livello (a.k.a. FPA stimato) – Questo metodo è considerato il metodo principale al giorno d'oggi, poiché la maggior parte della documentazione funzionale manca dei dettagli per poter utilizzare lo standard Nesma (o IFPUG) FPA. L'FPA di alto livello utilizza una valutazione della complessità fissa per componente funzionale di base: bassa complessità per i file logici e media complessità per le funzioni. Questo metodo può essere utilizzato quando il modello di dati e le funzioni sono noti, ma i dettagli di quali attributi vengono utilizzati in quali funzioni mancano o sono incompleti (che è spesso il caso). La precisione di questo metodo è intorno -8% per +15% (vedere questo articolo).

Inoltre, Nesma distingue tra dimensione del progetto (il numero di punti funzione aggiunti a un sistema esistente, più il numero di punti funzione modificati nel sistema, più il numero di punti funzione eliminati, più punti funzione del software necessari per realizzare per completare il progetto, ad esempio software di conversione) e taglia del prodotto (la dimensione funzionale dell'applicazione che viene consegnata agli utenti).

Nesma è una comunità molto attiva di volontari che lavorano costantemente su nuovi modi per utilizzare il metodo su nuovi tipi o tipi speciali di progetti software. Sebbene questi non facciano ufficialmente parte dello standard ISO/IEC, questi metodi possono essere molto utili per la stima del software. Linee guida ampiamente utilizzate sono per esempio:

• FPA per il miglioramento del software
  l'uso di questo metodo è attualmente obbligatorio in alcuni paesi affinché gli appaltatori possano fare offerte per progetti governativi.
• FPA in ambienti SOA (solo in olandese)
• FPA nei progetti di data warehouse
• FPA nelle prime fasi del ciclo di vita del progetto
• FPA applicato a Usecase / Documentazione UML

Il Basis of Estimate (BoE) per i servizi software come pubblicato da Nesma e il AACE Internazionale, l'autorità per la gestione dei costi totali, è un modo molto utile per basare qualsiasi stima del progetto software, dimostrando anche che lo stimatore ha tenuto conto di tutti gli aspetti importanti nella sua stima. Il Nesma (IFPUG) metodo è supportato dalla maggior parte dei modelli e degli strumenti di stima software parametrici commerciali e non commerciali.

Le caratteristiche per valutare l'utilità di questo metodo per la stima del progetto software sono elencate nella tabella successiva:

Caratteristica	S/N	Osservazioni
Obbiettivo, ripetibile, verificabile e difendibile	sì	ISO / IEC 24570:2004
Dati storici disponibili	sì	ISBSG R13: 187 progetti (5433 quando combinato con IFPUG)
Supportato da modelli/strumenti	sì	QSM, VEGGENTE-SEM, Vera pianificazione, COCOMO II, ISBSG

 

IFPUG

Il metodo IFPUG è il metodo più utilizzato per la misurazione delle dimensioni funzionali. Di tutti i requisiti, Misura solo i requisiti funzionali dell'utente e lo fa nel modo in cui i file logici interni (ILF), file di interfaccia esterna (FEI), funzioni di ingresso esterno (NO), funzioni di output esterno (È IL) e inchiesta esterna (EQ) le funzioni sono identificate e classificate in complessità. La complessità del software è classificata nel modo seguente: Basso, Medio o Alto, a seconda di elementi come il numero di attributi di dati coinvolti, il numero di file a cui si fa riferimento o il numero di tipi di record che fanno parte del file logico. Per un file logico interno (ILF) per esempio, il numero di punti funzione connessi a un ILF a bassa complessità è 7 punti funzione (FP), ottiene un ILF di media complessità 10 FP e un ILF di elevata complessità ottiene 15 FP. C'è un numero minimo di punti per funzione e un numero massimo di punti per funzione. Sebbene ciò semplifichi in qualche modo il processo di analisi, è percepito come un inconveniente che potrebbe non esserci abbastanza sfumatura tra le dimensioni di diversi file logici e funzioni. Ad esempio, la dimensione di una complessa funzione di input esterno è 6 FP, ma è la dimensione di un EI molto complesso 6 anche i punti e lo è anche la dimensione di un EI estremamente complesso 6 FP.

Il metodo IFPUG è molto utile come metodo di dimensionamento per stimare i progetti che soddisfano le seguenti caratteristiche (non limitato):

• Il software è orientato ai dati, molti CRUD (Creare, Leggere, Aggiornare, Elimina) le funzioni sono specificate
• Il software è orientato all'amministrazione
• È disponibile un progetto funzionale dettagliato in cui il modello di dati è completo e chiaro e per tutte le funzioni è chiaro quali attributi di dati vengono utilizzati

Quando si misura la dimensione dei requisiti funzionali, ci sono numerosi modi per convertirlo in una stima. Utilizzare i dati storici dell'organizzazione che realizzerà il software è solitamente la strada migliore da percorrere, preferibilmente supportato da strumenti di stima professionali. Se i dati storici non sono disponibili, il database aperto dell'International Software Benchmarking Standards Group può rivelarsi molto utile. Contiene oltre 6700 progetti (pubblicazione 13) e molti di questi sono stati misurati in IFPUG. Il metodo IFPUG è supportato dalla maggior parte dei modelli e degli strumenti di stima software parametrici commerciali e non commerciali.

Le caratteristiche per valutare l'utilità di questo metodo per la stima del progetto software sono elencate nella tabella successiva:

Caratteristica	S/N	Osservazioni
Obbiettivo, ripetibile, verificabile e difendibile	sì	ISO / IEC 20926:2009
Dati storici disponibili	sì	ISBSG R13: 5244 progetti
Supportato da modelli/strumenti	sì	QSM, VEGGENTE-SEM, Vera pianificazione, COCOMO II, ISBSG

 

COSMICO

Consorzio internazionale per la misurazione del software comune (COSMICO) è un volontario, raggruppamento mondiale di esperti di metriche del software. Iniziato il 1998, COSMIC ha sviluppato un metodo per misurare la dimensione funzionale del software progettato per superare alcuni dei difetti percepiti di Nesma e IFPUG FPA. Mentre Nesma e IFPUG sono utilizzati principalmente per misurare le dimensioni del software amministrativo, COSMIC è applicabile anche per misurare le dimensioni del software in tempo reale e dell'infrastruttura. Il metodo è interamente "aperto"; tutta la documentazione del metodo è disponibile nel pubblico dominio per il download gratuito.

Uno dei principali vantaggi del metodo COSMIC è il fatto che consente allo specialista della misurazione di suddividere il software in livelli software e componenti pari, che consente la possibilità di misurare la dimensione funzionale del software che risiede in strati di architettura separati o in diversi componenti che comunicano tra loro. Ciò supera uno degli svantaggi percepiti dei metodi Nesma e IFPUG, che non consentono di suddividere il software in questo modo.

Un altro importante vantaggio è il fatto che il metodo segue una scala di rapporti. Pertanto la dimensione funzionale per processo funzionale può essere qualsiasi dimensione tra 2 Punti funzione COSMIC (il valore minimo per processo funzionale) e (teoricamente) infinito.

Di solito il metodo COSMIC è molto ben applicabile all'uso in progetti sviluppati con una metodologia agile. Il tipo di documentazione che questo tipo di progetti spesso fornisce (per esempio. storie degli utenti, casi d'uso, diagrammi di attività, diagrammi di sequenza, diagrammi di classe) sono solitamente facili da misurare con COSMIC in modo molto accurato.

Sebbene l'uso di COSMIC sia in aumento e anche il numero di professionisti certificati sta aumentando, ancora non sono disponibili molti dati di benchmark aperti. Il rilascio del repository ISBSG New Developments and Enhancements 13 (rilasciato febbraio 2014) contiene circa 500 progetti misurati in COSMIC, mentre il numero di progetti misurati in punti funzione IFPUG è ben al di sopra 5000 progetti.

Il metodo COSMIC è solitamente particolarmente applicabile quando si utilizza la dimensione funzionale per stimare i seguenti tipi di progetti:

• Progetti software in tempo reale;
• Progetti software per app mobili;
• Progetti software di infrastruttura;
• Progetti software che forniscono software in un'architettura a più livelli;
• Progetti software amministrativi.

La documentazione funzionale dovrebbe almeno mostrare i processi funzionali implementati dal software ei movimenti di dati tra gli utenti e il software.

Le caratteristiche per valutare l'utilità di questo metodo per la stima del progetto software sono elencate nella tabella successiva:

Caratteristica	S/N	Osservazioni
Obbiettivo, ripetibile, verificabile e difendibile	sì	ISO / IEC 19761:2003
Dati storici disponibili	sì	ISBSG R13: 488
Supportato da modelli/strumenti	sì	QSM, VEGGENTE-SEM, Vera pianificazione, ISBSG

Esistono altri due standard ISO/IEC per la misurazione delle dimensioni funzionali, FiSMA e Mark II, ma poiché questi metodi sono utilizzati solo in specifiche comunità locali, non sono discussi in questo documento.

Tutti i metodi per la misurazione della dimensione funzionale sono molto adatti per la stima del progetto software. La dimensione del software tuttavia è solo una parte della stima. La dimensione dovrebbe essere convertita in una stima utilizzando i dati storici di produttività pertinenti. Quando la dimensione funzionale in punti funzione è nota, dovrebbe essere moltiplicato per il numero più probabile di ore per punto funzione che sarà probabilmente necessario nel progetto. Sebbene siano disponibili diversi strumenti parametrici professionali, e anche banche dati con dati storici possono essere procurati facilmente, molte organizzazioni ritengono che sia complicato e dispendioso in termini di tempo utilizzare la misurazione delle dimensioni funzionali e trovano difficile determinare un tasso di produttività accurato per i progetti che devono stimare. Preferiscono metodi meno dispendiosi in termini di tempo o metodi più facili da applicare. purtroppo, questo significa anche che questi metodi potrebbero non essere altrettanto accurati.

Prossimo blog

Nel prossimo blog su questo argomento, Darò la mia opinione sull'utilità dei principali metodi di misurazione delle dimensioni non funzionali per la stima del progetto software.

 

Circa l'autore

Harold van Heeringen è consulente senior di benchmarking presso Metri. A parte il suo lavoro per Metri, è coinvolto in Nesma (membro di bordo), l'International Software Benchmarking Standards Group (ISBSG, attuale presidente) e il Common Software Metrics International Consortium (COSMICO, Consiglio consultivo internazionale, in rappresentanza dei Paesi Bassi).

Un post sul blog rappresenta l'opinione personale dell'autore
e potrebbe non coincidere necessariamente con le politiche ufficiali di Nesma.