Qual è la relazione tra il tempo necessario per sviluppare N linee di codice e 4N linee di codice?

Le persone hanno sviluppato una serie di modelli per tentare di stimare cose come questa. Anche se non proverei a sostenere che nessuno di loro è assolutamente affidabile o accurato, ci sono alcuni che sembrano prendere in considerazione un numero sufficiente di fattori per fornire stime ragionevoli a metà.

Solo per un esempio, il modello COCOMO II di Barry Boehm sembra adattarsi alla tua situazione abbastanza bene. Secondo una implementazione online , il tuo KLOC 1 originale dovrebbe richiedere circa 4 mesi di sforzi e i tuoi 4 KLOC dovrebbe richiedere circa 10 mesi persona (per una serie di ipotesi - sentiti libero di inserire valori più appropriati per il tipo di sviluppo e simili).

Allo stesso tempo, dovrei essere d'accordo con altri che hanno sottolineato che le linee di codice raramente sono una misura molto buona (di gran parte di qualsiasi cosa). La stima basata sui punti di funzione (per una possibilità) mi sembra piuttosto più accurata. Anche nel migliore dei casi, tuttavia, richiederà molto più lavoro, e potrebbe essere aperto a chiedersi se produce risultati sufficientemente accurati o affidabili da giustificare tale lavoro, specialmente per un progetto abbastanza piccolo come questo.

Modifica: Oops - Ho incollato il link sbagliato (che era per il modello originale COCOMO, non COCOMO II). COCOMO II ha un po 'più di lavoro da usare (potrebbe richiedere un minuto o due invece di 30 secondi), ma produce (cosa dovrebbero essere) risultati più accurati. Implementazioni online sono disponibili. Sicuramente tenta di tenere conto di più fattori in ogni caso (ad esempio, se è possibile riutilizzare una o tutte le 1000 righe di codice esistenti nel nuovo progetto).

Le applicazioni non possono essere quantificate in termini di LOC: semplicemente non funziona. mai . Quindi, per favore, risparmia la seccatura e non farlo.

Modifica: a meno che non si tratti di una domanda a casa ... nel qual caso il professore è un idiota e dovresti andare in una scuola migliore - n ^ 2

Questo è un po 'controverso, ma per lo SLOC di gestione del progetto viene in genere utilizzato per determinare quali sono le scadenze stimate (ovvero leggere Stima del software : Demystifying the Black Art (Best Practices (Microsoft)) ); tuttavia, ciò che viene di solito sottolineato di volta in volta è che hai bisogno di un insieme di dati abbastanza grande di problemi simili che puoi iniziare a notare le tendenze in quanto tempo è necessario per sviluppare le cose. Nota che questo si applica anche a basi di codice molto grandi e non inizi a vedere stime accurate finché non sei nello SLOC di 100.000.

Per costruire su MainMa's un'analogia subacquea un po ', se stai guidando in una grande città e tutti i viaggi sono meno di 50 km potresti eventualmente essere in grado di dire con una certa sicurezza che il viaggio occorrono circa 30 minuti in condizioni di traffico normali, ma l'intervallo di un singolo viaggio potrebbe richiedere tra 15 minuti e 2 ore per ogni istanza data.

Questo è simile al tentativo di stimare quanto tempo ci vorrà per scrivere una determinata funzione o un punto della storia poiché non tutti sono uguali. La risoluzione di un punto della storia che implica solo ottenere alcuni dati e convertirli in un rapporto potrebbe richiedere solo un paio d'ore per qualcuno che abbia familiarità con il progetto, in quanto, nel tentativo di migliorare alcuni codici di accodamento sottostanti, il programma potrebbe impiegare diversi giorni. Questo è generalmente il luogo in cui la pianificazione basata sull'evidenza è migliore in quanto lo sviluppatore è quello che guida la stima basata sulla loro esperienza con l'attività assegnata e quindi aggiustare le cose sulla base delle prove storiche relative allo sviluppatore, ecco perché questa tecnica tende ad essere migliore per la stima delle attività.

Tornando agli SLOC come precedentemente notato, possono essere utilizzati per stimare quando un grande progetto sarà completato ma solo su larga scala e quindi non ridimensionerà molto bene e richiederà prove storiche di progetti simili in condizioni simili generare la stima della linea temporale e in realtà vengono utilizzati solo come guida alla fine della giornata. Tornando all'analogia subacquea. Questo è simile ai viaggi su strada a lungo raggio (cioè a partire da 1.500 km) poiché l'enorme quantità di distanza garantisce che anche se potresti incappare in parti del viaggio in cui strisciate nel traffico, incontrerete anche i momenti in cui potete andare limite di velocità per un periodo prolungato di tempo. Ciò significa che, dopo aver effettuato il viaggio un paio di volte, è possibile fornire una stima abbastanza ragionevole della velocità media del viaggio e del tempo necessario per passare dal punto A al punto B. I progetti di grandi dimensioni sono uguali modo: le dimensioni del progetto consentono ai progettisti di poter dire che, "Abbiamo fatto un progetto di portata simile prima, in passato, sarà probabilmente grande come quei progetti, quindi sarà probabilmente il momento di completarlo essere simile a loro. "

Se vuoi che il tuo codice abbia meno bug, dovresti scrivere molti test automatici, e farlo prima e mentre scrivi il codice, e non dopo un componente è pronto. Esistono framework di test per diverse lingue e piattaforme. Puoi leggere su Test Driven Development, ci sono molte risorse online e offline sull'argomento.

Il tempo (T) richiesto per lo sviluppo (di un programma) non è solo la funzione delle righe di codice (SLOC). È anche funzione di qualità (Q) (e probabilmente n + 1 più variabili).

Se Q è basso, T cresce leggermente in modo lineare con SLOC. (Basta battere più linee di codice, ed è più o meno un'attività fisica).

Quando Q diventa più alto T inizia a crescere in modo esponenziale e si avvicina sempre di più all'infinito. (È molto difficile scrivere un codice totalmente privo di bug di più di tre SLOC).

Quindi, penso, è quasi impossibile stimare T se solo dato SLOC. Forse, se sei fortunato potresti colpire nell'intervallo di + -1 ordine di grandezza. Per esempio. stimati 10 giorni e potrebbe richiedere qualcosa tra 1 e 100 giorni.

Le linee 4K di codice semplice potrebbero impiegare 1/10 del tempo come linee 1K di codice complesso. E le linee 4K di codice complesso potrebbero richiedere 40 volte come linee semplici da 1K. La misura non ha senso.

Non puoi semplicemente guardare LOC / SLOC da solo come stai provando. L'unico modo per utilizzare le LOC con un certo grado di successo (e come linea guida, non come una regola infallibile) dai progetti precedenti per stimare le dimensioni future del progetto è di avere un numero decente di progetti con il loro SLOC, numero di risorse (sviluppatori) e tempo di completamento contabilizzati. Quindi puoi usarlo per estrapolare.

Ma per portare un solo progetto, un singolo progetto, specialmente uno non così grande (1K è piuttosto piccolo), sono solo troppi pochi dati per utilizzare le metriche LOC in qualsiasi modo significativo.

Se questo è un compito a casa, il tuo professore è un idiota senza tracce.

Tuttavia, se questo è reale, e se sei davvero premuto, puoi utilizzare le seguenti linee guida:

EXPECTED_COMPLETION_TIME = 
  ( PREVIOUS_COMPLETION_TIME / PREVIOUS_KLOC ) * EXPECTED_KLOC * SPILLOFF

Con SPILLOFF = 1 che ti dà una probabilità del 30% di successo (una probabilità del 70% di fallimento), SPILLOFF = 1.5 ti dà una probabilità del 60% di successo (una probabilità del 40% di fallimento) e SPILLOFF = 2 dandoti un 90% di possibilità di successo (una probabilità di fallimento di $ 10). Il motivo dell'utilizzo di tali stime è che i fallimenti nel completamento dei progetti software tendono ad esibire una distribuzione esponenziale rispetto al tempo assegnato per allocazione temporale (o qualunque altra risorsa tu scelga di utilizzare.)

Quando hai un lavoro coerente all'interno di un'organizzazione o quando lavori in ambienti simili, e la tecnologia (non solo il linguaggio, ma la tecnologia) e i processi sono uniformi, allora puoi fare delle stime con alcuni margini di errore basati su progetti precedenti. In questi casi, vuoi dare più peso ai progetti più recenti.

Dì, per gli ultimi n + 1 progetti (diciamo n + 1 = 5 o 10 ... avviso, è n + 1, non n), potresti fare quanto segue ma solo se mantieni attentamente il numero di persone coinvolte in un progetto, numero effettivo di LOC, tempo di completamento effettivo e tempo stimato di completamento stimato prima dell'inizio del progetto.

SUM = 0
FOR i = 1 to n
  KLOC_PER_HEAD(i) = KLOC(i) / TEAM_SIZE(i)
  ACTUAL_COST(i) = ACTUAL_COMPLETION_TIME(i) / KLOC_PER_HEAD(i)
  RUNOFF(i) = ACTUAL_COMPLETION_TIME(i) / ORIGINALLY_ESTIMATED_TIME(i)

  SUM = ( ACTUAL_COST(i) * RUNNOF(i) ) + SUM
END 

LAST_COST = ACTUAL_COST(n+1) = ACTUAL_COMPLETION_TIME(n+1) / KLOC_PER_HEAD(n+1)
LAST_RUNNOF = ACTUAL_COMPLETION_TIME(n+1) / ORIGINALLY_ESTIMATED_TIME(n+1)
LAST = LAST_COST * LAST_RUNNOF

ESTIMATE = ( ( (SUM / (n + 1) ) + LAST ) / 2 ) * SPILLOFF

Con SPILLOF come definito in precedenza.