Annuncio di notizie IFPUG
Ora che l'IFPUG ha pubblicato Citazione #3, gli utenti del metodo IFPUG ora hanno ufficialmente ottenuto il via libera per utilizzare metodi di stima delle dimensioni che possono essere utilizzati prima nel ciclo di vita del progetto software rispetto al momento di un progetto funzionale completato. In uTip #3 i metodi High Level FPA (In Nesma spesso chiamato "FPA globale" o "FPA stimato") e FPA indicativo sono descritti. Sono davvero metodi molto utili per stimare la dimensione di un'applicazione (o progetto) e molte organizzazioni commerciali e governi in tutto il mondo utilizzano questi metodi da molti anni. Infatti, in pratica la documentazione funzionale è molto raramente completa e sufficientemente dettagliata per eseguire un FPA dettagliato all'inizio del ciclo di vita del progetto software in quanto è necessario per stimare il progetto. Questo è in realtà un argomento avanzato da molti project manager per non utilizzare FPA, poiché presumono erroneamente che una misurazione FPA possa essere eseguita solo su un progetto funzionale completo, che è troppo tardi nel ciclo di vita del progetto per essere utile per loro ai fini della stima.
Soprattutto con l'industria che si sta allontanando dalle metodologie di sviluppo tradizionali verso metodologie più agili, la documentazione funzionale sufficientemente completa e dettagliata per eseguire un FPA dettagliato diventa sempre più rara, quindi non c'è altra scelta che adottare un metodo stimato per poter misurare/stimare la dimensione funzionale.
Ovviamente, con qualsiasi stima di qualsiasi cosa... bisognerebbe chiedersi quale sarebbe l'accuratezza della stima e qual è l'incertezza che viene introdotta a causa della stima. La buona notizia è che sono stati pubblicati studi in cui è stata studiata l'accuratezza del metodo FPA di alto livello e del metodo indicativo rispetto a un FPA dettagliato. In Sogeti Olanda per esempio, il reparto Dimensionamento, stima & Controllo (SEZ) presentato A carta sul Software Measurement European Forum di Roma (Italia), nel mese di giugno 2009, in cui la perdita di precisione e risparmio di fatica sull'uso dell'APP di alto livello e dell'APP indicativo di 42 progetti è stato studiato rispetto a misurazioni FPA dettagliate.
Sebbene per questo studio sia stato utilizzato il metodo Nesma, i risultati di quello studio dovrebbero essere paragonabili anche al metodo IFPUG, come ci sono pochissime differenze tra i due metodi in pratica al giorno d'oggi.
Il carta, compresi i dati di misurazione, è disponibile sul articoli pagina. Le principali conclusioni dello studio sono elencate nella tabella sottostante:
| Metodo | Precisione | Perdita di precisione | Diamo un'occhiata più da vicino a queste metriche principali | Guadagno di fatica |
|---|---|---|---|---|
| Media | Media | |||
| Dettagliato | 100% | 100 norma ore | ||
| Alto livello* | 98.5% | 1.5% | 67 norma ore | 33% |
| Indicativo | 83.5% | 16.5% | 18 norma ore | 82% |
* L'High Level FPA è anche chiamato "FPA globale" o "FPA stimato" nel metodo Nesma
Si scopre che l'utilizzo del metodo FPA di alto livello in media produce solo risultati 1,5% perdita di precisione, che di solito non è un grosso problema all'inizio del ciclo di vita del progetto software. Il metodo indicativo è in media un po' meno accurato, ma poiché questo metodo può essere utilizzato anche prima nel ciclo di vita del progetto software (quando solo il numero di file logici è noto o può essere determinato), questo metodo è molto utile per creare un primo "ordine di grandezza approssimativo". (rom)stima della dimensione funzionale attesa.
La colonna delle ore di sforzo mostra le ore normalizzate anziché le ore reali. Ciò significa che il metodo stimato richiede in media 67% del tempo da misurare rispetto a una misurazione FPA dettagliata. Il metodo indicativo FPA richiede in media 18% dello sforzo di una misurazione FPA dettagliata.
Riguardo agli Autori
Harold van Heeringen, Edwin van Gorp e Theo Prins sono consulenti di software metrics / ingegneri dei costi del software per Sogeti Nederland B.V. Pubblicano regolarmente in conferenze internazionali sugli aspetti pratici della misurazione del software. La maggior parte dei loro articoli può essere trovata su articoli pagina.
Quale percentuale delle tue analisi FP utilizza il metodo dettagliato? Facci sapere sul Forum.
Harold e Teo: Grazie per aver postato questo.
Ho utilizzato il metodo FPA leggero negli ultimi dieci anni per un paio di motivi:
– Le prime stime richiedono una visione di alto livello sulla dimensione funzionale. Un'analisi fp dettagliata porterebbe a credere che ci sia accuratezza dove non può esserci.
– Anche in un'analisi di base, i miei clienti spesso non sono in grado di fornire una panoramica dettagliata sull'implementazione dei singoli attributi. Mancanza di documentazione, mancanza di conoscenza, mancanza di niente…. le ragioni sono molteplici.
– Di solito offro preventivi a prezzo fisso, quindi essere economicamente vantaggioso, l'analisi di alto livello è la scelta migliore.
– Non voglio annoiare il pubblico. I clienti sono abbastanza soddisfatti quando finisco un'enorme applicazione SAP all'interno 2 giorni (“Abbiamo sempre pensato che ci sarebbero volute settimane, … come può essere che la stima richieda solo 2 giorni….”). E non vogliamo tutti clienti felici?
Solo in un'occasione ho quasi cominciato a sudare: Avevo addestrato persone di una grande azienda di telecomunicazioni nell'analisi light-FPA. Avevamo contato il volume dei risultati di sviluppo di 12 mesi dell'organizzazione. Dopo aver riportato i risultati fp, la direzione non osava fidarsi né di me né del proprio personale, chissà? Quindi hanno volato in un'altra società di metriche (li fanno sempre volare da molto lontano, sperando che questo lo renda più efficace) rifare l'intera analisi utilizzando il metodo IFPUG dettagliato.
Indovina cosa è successo allora, non è vero?? Hanno trovato meno di 1% deviazione tra la nostra analisi della luce e la loro analisi dettagliata!
Penso che il guadagno di sforzo riportato sia piuttosto conservativo e possa dipendere dai tuoi standard di reporting. Nel suo confronto (2 settimane contro 2 giorni) Eva mostra uno sforzo guadagnato di 80% per un'analisi di alto livello. La mia esperienza è simile: almeno un'analisi di alto livello 4 volte più veloce di un'analisi dettagliata.
Alla conferenza sulla fiducia nell'IT (Tokio, ottobre 2014), Una presentazione è stata fatta da ricercatori giapponesi che hanno accreditato il metodo Nesma High Level FPA come responsabile del crescente interesse nell'uso del dimensionamento funzionale nell'industria giapponese. Sto cercando di ottenere la presentazione, ma è già disponibile un breve documento, anche tramite ISBSG slideshare: http://www.slideshare.net/ISBSG/matsumoto-towards-an-early-software-effort-estimation-based-on-the-nesma-method-estimated-fp
Sono stato molto sorpreso di sentire che IFPUG ha annunciato FPA uTIP#3 "Early FPA". Più di 10 anni di "analisi stimata" del NESMA’ (che è identico all'analisi di alto livello) è una pratica comune nella scena della consulenza metrica olandese.
Le tabelle nel blog mostrano in modo inequivocabile che c'è solo una leggera differenza di dimensioni tra l'analisi dettagliata e l'analisi stimata. Quindi si può concludere che l'accuratezza di "alto livello".’ l'analisi è buona quasi quanto l'analisi dettagliata, con un notevole guadagno di fatica.
Secondo me il vero vantaggio è quell'alto livello’ L'FPA può essere applicato a specifiche a grana più grossa, quindi all'inizio del progetto. Nella mia pratica ciò significa che una stima delle dimensioni e una stima del progetto abbastanza accurate possono essere rapidamente fornite alla fine dell'analisi dei requisiti (e prima della progettazione esecutiva). Sono molto curioso della "stima dei costi coerente".’ dell'IFPUG.
Grazie per questo post; è abbastanza utile. Abbiamo utilizzato Quick FPA in molte situazioni, e l'accuratezza della stima è sempre dibattuta. Questa analisi sarebbe utile!