Quanto sono utili i punti di funzione? [chiuso]

Personalmente, non ho mai trovato una risposta esplicita alla domanda "Che cos'è un punto funzione?" Senza di questo, sono VERAMENTE esitante su qualsiasi metodologia di stima che afferma di fare qualsiasi cosa con Function Points.

La singola parte più importante di una seria metodologia di stima del software è la "ricalibrazione periodica degli effettivi", il che significa che fai la tua stima, la scrivi e poi, quando il progetto è finito, confronti i tuoi risultati effettivi con i tuoi stimare e, se necessario, rivedere il processo di stima. INCLUSO IN QUESTO confronta gli INGRESSI con il tuo processo di stima con gli INGRESSI EFFETTIVI.

Se, ad esempio, si stimano le Linee di codice sorgente (SLOC) e si passa da lì, si deve confrontare il proprio SLOC effettivamente consegnato con lo SLOC stimato e vedere se, fino a dove e dove e perché si è andato fuori strada . Uno stimatore che predice perfettamente le ore uomo, data una stima SLOC accurata e precisa, non ti farà nulla di buono se le tue stime SLOC non valgono nulla. Immondizia, spazzatura. (La stessa cosa vale per i Function Point.)

Se i tuoi effettivi SLOC (o Function Point) corrispondono alle tue stime iniziali, puoi esaminare i costi effettivi rispetto ai costi stimati e regolare i parametri dello stimatore per migliorare i risultati. La divisione General Dynamics / Fort Worth ha fatto questo esercizio, in dettaglio, nei primi anni '80, per lo sviluppo del software F-16C / D, e quindi per diversi anni avrebbe puntualmente puntato sul risultato netto dell'azienda su tali stime. GD / FW è stata la mucca da soldi di GD per un bel po ', mantenendo a galla il resto dell'azienda, quindi devono aver fatto qualcosa di giusto.

E nota che i requisiti e lo scorrimento delle funzionalità sono IL NEMICO della stima del software.

(Questa è una modifica successiva.) L'ultimo punto di Bernd merita una risposta. Chiede cosa dovrebbe essere fatto per i progetti che arrivano in anticipo e non spendono tutte le ore lavorative assegnate.

Questo è tanto un errore di stima quanto lo scadere (molto più comune) del programma. Il nocciolo della questione è questo: se tutti i tuoi progetti superano il loro programma, i tuoi stimanti non stanno facendo il loro lavoro.

Se le persone che stanno valutando stanno facendo tutto nel modo giusto, e i tuoi manager stanno facendo tutto bene, allora farai in modo che alcuni progetti arrivino in anticipo, insieme a quelli che arriveranno in ritardo. Le stime sono probabilità. Proteggi il tuo estimatore per eliminare i sottocapitoli di pianificazione e, PER DEFINIZIONE, aumenta la probabilità di sovraccarichi del programma. Se la tua gestione richiede pianificazioni e stime con zero possibilità di underrun, allora fornirai orari che SARANNO essere superati, garantiti, e poi inizierai a visualizzare le richieste per Death Marches, e poi inizierai vedendo le dimissioni, e i tuoi superamenti ottengono molto, molto peggio, mentre cerchi di reclutare sostituti (e si sparge la voce che la tua azienda è una realtà produttiva).

Quando si ha a che fare con lo scopo di un progetto, generalmente è meglio usare una misura di Function Point piuttosto che Linee di codice . Poiché i progetti software possono avere fino a milioni di LOC (incluso LOC nelle librerie), il numero diventa relativamente privo di significato.

Come si misura LOC se si chiama funzionalità dalle librerie? Includete LOC dalle biblioteche? Se non includi LOC dalle biblioteche, il tuo capo non sta scrivendo abbastanza LOC?

In generale, è meglio dire "Ho completato la funzionalità XXX" anziché "Ho scritto XXX righe di codice".

Ma ti suggerisco di vedere di persona. È più facile per te stimare i punti di funzione o Linee di codice? Collega questi risultati al modello COCOMO II e vedi quale è più facile da usare.

Inoltre, questo manuale COCOMO II fornisce una descrizione dettagliata dei punti di funzione e LOC intorno a pagina 11. Speriamo che sia sufficiente per andare avanti.

Lavoro in un'organizzazione in cui abbiamo introdotto punti funzione per il calcolo di progetti a prezzo fisso, ovvero il cliente e contiamo in base a specifiche, concordiamo il conteggio e moltiplichiamo il #FP con un prezzo FP per determinare il prezzo del progetto. Tutto questo in un ambiente con un fatturato annuale di due milioni di Euro. L'intenzione è rimuovere l'ambiguità e la negoziazione dalla determinazione dei prezzi che è stata una costante causa di attrito.

Abbiamo effettuato una calibrazione iniziale, valutando circa 2 anni di storia del progetto per un valore di due milioni di Euro.

Vediamo chiaramente che #FP e costi del progetto si corrompono in modo molto indiretto. Deviazioni del +/- 50% sono ragionevolmente possibili. Tuttavia, vediamo (beh, ci aspettiamo, o meglio: speriamo) che nel lungo periodo i punti di funzione e i costi del progetto convergono.

Ora siamo in procinto di implementarlo nell'organizzazione e nell'esperienza (da un punto di vista della cena):

• Discussioni sulle applicazioni delle regole di conteggio FP. Ci sono degli standard su questo, tuttavia, questi sono soggetti a negligenza se non si può discutere direttamente sui prezzi.

• Le impressioni del cliente che i prezzi sono aumentati, nonostante gli sforzi che abbiamo speso e stiamo spendendo nella calibrazione e nella verifica della calibrazione. La ragione presunta è che questa procedura rende i costi brutalmente chiari, nessun modo per nascondere, spostare o coprire i costi in alcuni progetti "non chiedere" o strategici.

• Necessità di gestire progetti che non coprono i costi (underscoot del 50% ...)

Sembrano essere marginalmente utili nell'esprimere la complessità di un determinato sistema / componente e possono aiutare i manager / team a condurre il lavoro di ripartizione, ma non sono davvero più utili di altre metriche sintetiche / arbitrarie (SLOC, Cyclomatic Complessità, ecc.) Cioè, possono dare un'indicazione della quantità relativa di sforzo richiesto per parti specifiche di un sistema, ma non c'è modo di mapparli a stime concrete.

L'uso di punti funzione a favore di linee di codice cerca di risolvere diversi problemi aggiuntivi:

• Il rischio di "inflazione" delle linee di codice create e quindi la riduzione del valore del sistema di misurazione, se gli sviluppatori sono incentivati a essere più produttivi. I sostenitori di FP si riferiscono a questo come a misurare la dimensione della soluzione invece della dimensione del problema.

• Le misure di linee di codice (LOC) premiano i linguaggi di basso livello perché sono necessarie più righe di codice per fornire una quantità simile di funzionalità a un linguaggio di livello superiore. C. Jones offre un metodo per correggerlo nel suo lavoro.

• Le misure LOC non sono utili durante le fasi iniziali del progetto, in cui è stimolante stimare il numero di righe di codice che verranno consegnate. Tuttavia, i Function Point possono essere derivati dai requisiti e quindi sono utili in metodi come la stima per proxy.

Scappa.

Nella mia esperienza, le aziende che ho visto usano i punti funzione sono solo un gradino sopra la pura pazzia.