In genere stai eseguendo correttamente l'analisi dei punti funzione, e i risultati sembrano sensati. Tuttavia:
- Stai classificando erroneamente alcune uscite.
- Sei sorpreso dalla stima di COCOMO II per lo sforzo.
- Questa analisi ignora la realtà del moderno sviluppo web: il framework web probabilmente implementa già la gestione delle sessioni.
Che cos'è un ingresso esterno e un'uscita esterna?
Per un'interfaccia utente grafica, è meglio pensare a EI ed EO come schermi, widget o moduli . Pertanto, il tuo modulo di login è un input esterno. Stai classificando gli errori di convalida come output esterno separato. Non lo farei, poiché la validazione (e la limitazione della velocità, ecc.) È parte della funzionalità di accesso. Piuttosto, peserei la funzionalità di accesso con una complessità più elevata se dovessi fare una gestione degli errori speciale.
Classificerei i tuoi articoli come:
- Modulo di accesso: input esterno, media complessità. (giustificato da una logica aggiuntiva che limita la velocità e altre considerazioni di sicurezza)
- Modulo di registrazione: input esterno, semplice.
- Disconnessione e timeout della sessione: input esterno, semplice.
- Impostazioni di aggiornamento: Input esterno, semplice.
- Password dimenticata: input esterno, alta complessità. (sembra semplice, ma richiede un'accurata progettazione di sicurezza)
- Archiviazione sessione: file logico interno, semplice.
- Memoria dei dettagli dell'utente: file logico interno, semplice.
Esatto, non ci sono uscite esterne qui! Ma per essere onesti, questa applicazione non fa ancora nulla e fornisce solo un accesso. Se avessi uno schermo separato per la visualizzazione delle impostazioni rispetto all'aggiornamento delle impostazioni, lo considererei un EO semplice separato. Presumo anche che i vari punti in cui le credenziali di accesso vengono immesse dall'utente condividano un codice comune, quindi la complessità della gestione delle password è mediamente piuttosto semplice.
Utilizzando pesi complessi 3 × per EI semplici, 4 × per EI medie, 6 × per EI complessi, 4 × per semplici ILF, arrivo a un conteggio punti funzione di C = 27. Ciò è notevolmente inferiore alla stima, ma ancora nello stesso campo da baseball. Se si utilizzano i fattori di regolazione F i , questo potrebbe spostarsi più in alto o in basso.
Che cosa ci dice la stima di COCOMO II?
La stima non descrive solo il tempo impiegato per codificare quella funzionalità. Si tratta di una stima per l'intera durata del progetto e include una quantità di analisi, progettazione e test. Secondo una conferenza che ho ascoltato sull'argomento, solo circa il 30% dello sforzo stimato sarebbe destinato a compiti di sviluppo! Quindi se i 27 FP corrispondono a uno sforzo di circa 3,5 mesi-persona, circa 1 persona-mese di questo sarebbe il tempo di sviluppo.
Le stime che si ottengono da COCOMO tendono a sembrare incredibilmente lunghe, ma quando si inserisce tale contesto - grandi organizzazioni, livelli di abilità differenti, complicazioni e bug inaspettati, tutto il lavoro necessario per lo sviluppo del software che non è solo la codifica - sono un buon promemoria per non essere troppo ottimisti. Ovviamente è possibile essere più veloce, ma non devi scommettere su di esso. Quando l'analisi del punto di funzione viene eseguita in modo meticoloso e quando viene applicata a un progetto in cui FPA è una buona soluzione, i numeri tendono ad essere in un ordine di grandezza realistico.
Punti funzionali e sviluppo web.
Lo sviluppo Web è leggermente diverso.
Innanzitutto, esistono molti framework e librerie Web maturi che semplificano la creazione rapida di un sito Web solido (purché tu conosca già questo framework). Una singola persona esperta potrebbe probabilmente implementare i tuoi requisiti entro un giorno o una settimana - il login è così importante e fondamentale che il framework web potrebbe effettivamente insegnarti come farlo come un'applicazione "ciao mondo".
In secondo luogo, lo sviluppo web tende a coinvolgere molte più linee di codice, ma quelle non sono necessarie come difficili. Se si crea il modulo di accesso a mano, è necessario scrivere il modulo in HTML, modificarlo con CSS, magari eseguire controlli sul lato client con JavaScript, creare un URL in cui il modulo di accesso può eseguire il POST, quindi creare il codice di back-end effettivo che controlla la password. Potrebbe benissimo essere 400 linee di codice in totale, ma questo non significa che ci vorrebbe un intero mese. [1] Sono quindi diffidente nell'applicare COCOMO allo sviluppo web, dal momento che molto codice è boilerplate che viene scritto molto rapidamente.
[1]: Ovviamente un modulo di accesso può richiedere un mese per essere creato, ad es. quando è necessario un notevole sforzo di progettazione o speciali funzionalità di sicurezza. Sono sicuro che molti grandi siti web hanno speso molto più di quello in quel piccolo campo di testo.