Il parametro LOC è corretto per la stima del progetto?

Question

Il parametro LOC è corretto per la stima del progetto?

ci sono così tanti scenari in cui la complessità richiede molto più tempo per una singola riga di codice, diversa da LOC quale potrebbe essere il parametro suggerito per la stima del progetto?

Come i popoli parlano di punto funzionale del programma, ciò significa per le informazioni relative ai casi d'uso?

Sto cercando di trovare una solida base per la stima completa dello sviluppo del software che può consistere in analisi, progettazione, preparazione della testcase e codifica, per favore suggerire?

Answer 1

Solo se lo si utilizza nell'inverso.

- Modifica

Ma no. Non lo è. È una misura per lo più inutile e generalmente dannosa. Come si nota, meno codice è quasi sempre migliore.

Altre cose da verificare? Bene, cosa stai cercando di misurare? Quale risultato vuoi vedere da un cambiamento nelle cose che verificherai? Che tipo di decisioni prenderà sulla base di questi cambiamenti?

Answer 2

Steve McConnell in rapido sviluppo (Microsoft Press, 1996):

perché diversi di programmazione lingue producono tali scoppi differenti per un dato numero di linee di codice, gran parte del settore del software è in movimento verso una misura chiamata "punti funzione" per stimare le dimensioni del programma . Un punto funzionale è una misura sintetica della dimensione del programma basata su su una somma ponderata del numero di ingressi, uscite, richieste e file. I punti di funzione sono utili perché consentono di pensare alla dimensione del programma in un modo indipendente dalla lingua.

Google "Function Point" per ulteriori informazioni.

Answer 3

LOC è una misura proxy per misurare la dimensione del problema .

La stima LOC può essere utilizzata e il conteggio LOC è relativamente economico per misurare dai progetti storici. Ma LOC può essere problematico se usato per nient'altro che un proxy per la dimensione del problema, come già sottolineato da altre risposte.

La dimensione del problema è piuttosto costante in base ai requisiti. Da una stima delle dimensioni si può andare a sforzo, pianificazione e stime dei costi. Dipende dai tuoi fattori di pianificazione come il costo o la pianificazione. Dai dati storici è possibile trovare la correlazione su come la dimensione del problema si traduce in uno sforzo e su come altri fattori di pianificazione influenzano ulteriormente il risultato. Quindi è necessario misurare la misura delle dimensioni e lo sforzo rispetto ad altri parametri e continuare a perfezionare il processo di stima. Ci sono alcune misure LOC-to-effort disponibili in letteratura, ma non sono molto accurate nel tuo dominio, usando la tecnologia che stai utilizzando e il team che hai.

Altri proxy per la dimensione del problema sono punti funzione e punti della storia.La mia esperienza sui punti funzionali è che raramente ne vale la pena. D'altra parte, i punti della storia in metodi agili funzionano molto bene dal momento che sono volutamente astratta (evitando così un sacco di problemi con con LOC) e misurato su base sprint-by-sprint, con un feedback immediato in seguito sprint.

Answer 4

Visto che gli sviluppatori sono probabili * passare la maggior parte del loro tempo a cercare di testare le modifiche, le linee-di-codice non è mai un buon indicatore di dimensioni di un problema.

Supponiamo di avere un grande applicazione esistente - cambiare una sola riga di codice può sembrare banale, ma la pianificazione dei test e l'esecuzione potrebbe richiedere settimane.

Analogamente, l'aggiunta di una quantità relativamente grande di codice in un singolo modulo limitata portata che è facilmente verificabile potrebbe essere solo pochi giorni.

* che dovrebbero fare, almeno. Se passano più tempo a scrivere il codice che a testarlo, probabilmente è pieno di bug. E intendo PRIMA che arrivi alla tua squadra di QA dedicata.

Answer 5

No, non lo è. La ragione è semplice: se produci una nuova linea di codice durante lo sviluppo, sei un passo avanti verso una soluzione? Se hai stimato 1000 linee di codice per completare un'attività, ora sei completo allo 0,1% con quella attività?

Le righe di codice possono essere utilizzate come metrica ma solo in senso negativo: per un numero maggiore di righe di codice, è ragionevole assumere che si dispone di un numero maggiore di errori. Sulla base di dati storici, esiste generalmente una correlazione lineare tra le righe di codice e il conteggio degli errori.

Ecco alcuni fattori utili e misurabili che vale la pena considerare:

1. ore di lavoro.
2. Dollari spesi: questo è un buon modo perché rafforza fortemente la realtà che preferiresti trovare bug sul desktop dello sviluppatore che nelle mani di un tester o cliente).
3. Pietre miliari soddisfatte: il sistema è disponibile per i clienti alla data giusta?
4. Requisiti completati: questo può essere divertente - cosa succede se scopri una nuova esigenza del cliente durante il progetto?

In breve, le linee di codice sono quasi la metrica peggiore che si possa mai utilizzare.

Answer 6

L'unico modo per ottenere una stima ragionevole sulla durata del progetto è implementare COMPLETAMENTE e fornire alcuni sottoinsiemi dei requisiti finali. Quindi è possibile stimare i restanti requisiti confrontando la loro complessità con il lavoro completato.