Il costo stimato del progetto dipende da [SLOC | COCOMO]? [chiuso]

Non dovresti stimare in base a linee di codice sorgente. Dovresti stimare in base al tempo necessario per implementare le modifiche necessarie e ciò deriva dalla tua esperienza e dalla vasta conoscenza della tua base di codice.

Come hai detto, la stima basata su righe di codice sorgente potrebbe significare che gli sviluppatori scrivono di proposito più codice quando non è necessario. Perché dovresti rovinare il tuo codice base in questo modo?

La stima basata su LOC's è volutamente negativa e ho pensato che l'intero settore fosse passato da esso.

Comunque tu come sviluppatore dovresti sapere come valutare il tuo valore, se devi giustificare a un cliente il motivo per cui costa per una caratteristica specifica, allora è quello che dovrai fare.

I clienti / i padroni sono eccessivamente interessati a ciò che stanno ottenendo a un livello basso (in generale), a loro interessa il risultato. Per loro o il risultato vale la pena e sono felici di pagarlo perché raggiunge, o realizza ma pensano che fosse più denaro di quanto valesse.

E arrotondando all'indietro, dicendo al cliente quante linee di codice ci sono in un prodotto potrebbero farle andare "oh, figo!" e non cambiare il prezzo in quanto è completamente astratto. Ford ti dirà che c'è 160bhp nella tua Fiesta e ti fanno andare "oh, bello!" ma non li butti un altro £ 5k.

Parte del codice 1:

return this.Data.Products.Where(c => c.IsEnabled).GroupBy(c => c.Category).Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

Parte del codice 2:

return this.Data.Products
    .Where(c => c.IsEnabled)
    .GroupBy(c => c.Category)
    .Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

Parte del codice 3:

Func<Product, double> pricePredicate = c => c.Price;
Func<Product, bool> predicate = c => c.IsEnabled;
Func<Product, string> keySelector = c => c.Category;
Func<IGrouping<string, Product>, PricesPerCategory> finalSelector = c =>
    new PricesPerCategory(
        category: c.Key,
        minimum: c.Min(pricePredicate),
        maximum: c.Max(pricePredicate));

return this.Data.Products
    .Where(predicate)
    .GroupBy(keySelector)
    .Select(finalSelector);

Quei tre pezzi di codice fanno la stessa cosa e compilano molto probabilmente con lo stesso codice IL. Come puoi notare, la terza parte del codice non è leggibile perché sono state aggiunte variabili e righe di codice eccessive solo per far crescere la LOC riducendo al contempo la qualità del codice.

Perché qualcuno dovrebbe pagare di più per codice errato nel terzo esempio e pagare di meno per il codice migliore nel secondo?

Ogni volta che si presentano questi tipi di domande, penso sempre a questo articolo che ho letto in forma cartacea quando è stato pubblicato. Fortunatamente, è arrivato alla rete: link

In particolare, questa citazione è interessante:

In four months Barnaby wrote 137,000 lines of bullet-proof assembly language code. Rubenstein later checked with some friends from IBM who calculated Barnaby’s output as 42-man years.

Secondo l'articolo, ha scritto 137k righe di codice (implicito) abbastanza privo di difetti in quattro mesi. Alcuni altri individui hanno stimato questa uscita come 42 anni uomo.

Le stime possono combinare molte sfaccettature, incluso LOC, che possono essere utilizzate per "stimare" il costo nello sviluppo di un sistema.

Quindi la domanda è: preferiresti pagare Barnaby per i quattro mesi in cui ha lavorato al progetto o ai 42 anni che è stato stimato equivalente a?

So che questa non è una correlazione esatta, ma è qualcosa su cui riflettere.

Lo SLOC può essere un mezzo efficace per valutare i progetti quando vengono mantenute le metriche aziendali storiche. Inoltre, non è semplicemente una questione del progetto è x-numero di linee di codice e prezzo in base a quella singola metrica. Devi rompere il sistema in moduli e funzionalità. Quindi per ciascun modulo devi tenere conto di quanto è nuovo, di quanto viene riutilizzato, di quanto è stato ridisegnato, di quanto è generato automaticamente, del livello di difficoltà, della familiarità dello sviluppatore previsto con il modulo, dell'esperienza dello sviluppatore / della produttività livello, la piattaforma di destinazione e i risultati storici dell'azienda per funzionalità simili. Alla fine, questo fornisce un numero ESLOC (sforzo SLOC) che può quindi essere utilizzato per valutare il software. È un metodo provato e vero di citare il software utilizzato da molte aziende con successo. La chiave è che i record storici devono essere conservati poiché la cultura di un'azienda e il tipo di applicazioni sviluppate influenzano in modo significativo il programma.

Mentre il software di determinazione dei prezzi che utilizza SLOC funziona per molte aziende, va anche notato che è completamente inefficace nel valutare la produttività degli sviluppatori di software. I migliori sviluppatori di software scriveranno molte meno righe di codice di programmatori mediocri o cattivi, ma ottengono molte volte la funzionalità rispetto agli sviluppatori mediocri in quelle poche righe di codice. Infatti, i buoni sviluppatori tendono ad ottenere una produttività negativa (quando usano SLOC come metrica) quando entrano e rimettono a posto centinaia o migliaia di linee di codice degli sviluppatori mediocri perché avrebbero dovuto essere scritti in modo molto più pulito e più facile da capire .

No, non è una buona idea cercare di equiparare linee di codice con una quantità di lavoro. LOC può essere usato come una stima estremamente approssimativa per le dimensioni di un programma, ma questa è una caratteristica negativa. Non vuoi un programma più complesso di quello che deve essere. Anche il più semplice clone di tetris potrebbe avere milioni di righe di codice se reso orribilmente.

In alternativa, ti suggerisco di trovare un consulente che abbia le competenze per questo progetto. Mandagli una descrizione del lavoro e chiedi un preventivo. (Il che, dal momento che non hai intenzione di assumerlo, non è la cosa più bella da fare, quindi compralo a pranzo o qualcosa dopo).

I consulenti caricano un braccio e una gamba perché possono, teoricamente, entrare nell'esatta serie di competenze e nella base di conoscenze necessarie e possono portare a termine il lavoro rapidamente. Mostra questo preventivo e lui dovrebbe essere almeno un po 'più felice.

Il libero mercato è un fantastico mezzo per trovare il vero valore di una cosa.