Punti funzione di conteggio

1

Sto eseguendo un'analisi del punto funzionale (FPA) per un progetto. Sono completamente nuovo in questo processo e ho iniziato solo con i moduli di login e autenticazione per convalidare i risultati che ottengo.

Penso di aver capito bene i dati e il mio conteggio dei file di logica interna e dei file di interfaccia esterni è corretto. Ho bisogno di alcune indicazioni sul calcolo della funzione di transazione (EI, EO ed EQ).

Ecco le specifiche del processo:

  1. I nuovi utenti si registrano e quindi effettuano l'accesso
  2. L'utente esistente accede direttamente
  3. Sulla registrazione, i dati dell'utente raccolti e memorizzati.
  4. Al login controlli di convalida usuali: errori su credenziali non valide, altrimenti login riuscito
  5. Dettagli della sessione gestiti per gli utenti registrati.
  6. L'utente è stato sospeso temporaneamente dopo più di n accessi non validi.
  7. Sessione terminata automaticamente al timeout di inattività.
  8. Aggiorna le impostazioni email / password utilizzando la password dimenticata o le impostazioni di aggiornamento

Sto contando una parte molto essenziale di questo processo come EI / EO / ILF:

Ingressi esterni: 4

  • Accedi
  • Esci
  • Registrati
  • Aggiorna impostazioni

Uscite esterne: 3

  • Modulo di registrazione incompleto / non valido
  • Accesso non valido o utente limitato dopo tentativi non riusciti
  • Timeout sessione

File logici interni: 2

  • Dati utente
  • Dati di sessione

Nessuna query esterna o file di interfaccia esterna.

Nonostante il peso dei conteggi di cui sopra con bassa complessità, ottengo 38 UFP = 2014 SLOC (per Java: 53 SLOC per FP), che si trasforma in una stima di sforzo sorprendentemente alta quando si utilizza COCOMO II anche con i coefficienti più bassi.

Il mio dubbio non è legato al conteggio o alla complessità dei FP, sono più preoccupato se scelgo le cose giuste come EI o EO. Per quanto comprendo la tecnica FPA, tutte le informazioni di dati / controllo che entrano nel limite dell'applicazione vengono conteggiate come EI, quindi logicamente login, logout, registrazione, impostazioni di aggiornamento, password dimenticata sono tutti input. Allo stesso modo, login non valido, login riuscito, eventuali messaggi di errore relativi ai dati non validi, informazioni di timeout, ecc. Sono tutti output. Quindi ho ancora più EI ed EO di quanti ne ho contati sopra, ma poi il conteggio FP in uscita non è realistico.

Sto facendo correttamente l'FPA o ho frainteso qualcosa?

    
posta bvnbhati 07.05.2017 - 08:32
fonte

1 risposta

0

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.

    
risposta data 07.05.2017 - 14:50
fonte

Leggi altre domande sui tag