Quantitfying a costo per un progetto software [chiuso]

Cercherò di aiutarti a risolvere il tuo problema più che a rispondere alla tua domanda.

Ci sono molti sistemi per stimare i costi del software in anticipo. Perché non c'è solo uno? Perché non ce n'è uno che funzioni davvero. Un commento ha menzionato COCOMO-II, che ritengo sia accurato entro un fattore di 7 volte in entrambi i casi! (è dalla memoria, non riesco a trovare un riferimento, quindi prendilo con un pizzico di sale).

Non sarai in grado di dare a un cliente una stima con un fattore moltiplicare / dividere di 7.

Quindi, cosa fanno veramente le persone?

1. Fai offerte in modo conservativo e di solito perdi il contratto.
2. Fai offerte aggressive e perdi denaro il più delle volte.
3. Chiama il cliente a non fare offerte a prezzo fisso.
4. Fai offerte aggressive e poi guadagna i soldi più tardi.

L'articolo 4 riporta la spiegazione. Le tattiche più comuni sono:

1. Non fare nulla nei requisiti. Ad esempio, la qualità del codice è raramente un requisito. La formazione spesso non è un requisito. Per essere completamente completo, una specifica sarebbe un programma funzionante, quindi è possibile trovare quasi sempre le cose vitali non nelle specifiche.
2. Se ti viene chiesto di fare qualcosa che non sia nei requisiti, allora viene fatturata ogni ora, solitamente a un tasso elevato.
3. Di solito i bug devono essere corretti. Quindi ogni bug viene classificato come "design".

Questo è il motivo per cui molti progetti a prezzo fisso sono una battaglia senza fine tra le parti. Quanto male tende a essere basato su quanti soldi l'appaltatore sta perdendo, quanto è avido l'appaltatore, quanto è avido il cliente, e quanto dietro è stato stimato il progetto.

Se il processo va bene (il che può accadere, anche se non lo faccio sembrare in questo modo), gli elementi nelle specifiche che sono difficili da implementare possono essere scambiati con oggetti che sono stati dimenticati, il prezzo massimo (iniziale riparata le specifiche di prezzo più tutte le cose a cui nessuno pensava) è giusto, e tutti sono felici.

Se il processo va male, ciò che viene effettivamente implementato si basa su ciò che è nelle specifiche originali più il risultato di battaglie politiche sul denaro, e qualcuno perde denaro (probabilmente tutti).

Nella gestione di un progetto, se non ti pieghi sul prezzo, sul tempo o sulle funzionalità, ma non puoi controllare la qualità, indovina cosa soffre di solito? Il processo di offerta a prezzo fisso elimina all'inizio la possibilità di piegare il prezzo o le caratteristiche ed è generalmente strongmente contro la flessione in tempo. Sembra che ti piacerebbe essere giusto e fare un buon lavoro, ma capisci che è un modello difficile su cui lavorare.

Ti viene chiesto di trasformare i requisiti in ore e poi in ore in $. Non c'è una bacchetta magica per fare questo. Tutti i tuoi concorrenti cercheranno di fare gli stessi calcoli. Più esperienza hai, migliori saranno le tue stime.

Ogni requisito richiederà tempo per progettare, codificare e testare; più tempo per tutte le altre parti del progetto.

Non esiste un modo semplice per trasformare linee di requisiti in linee di codice e poi in ore.

Il rischio è che il cliente possa masticare settimane di approvazione approvando piccole modifiche o in una riunione di 30 minuti perché l'intero progetto viene spostato nel cestino (ho sentito che il linguaggio X è l'onda del futuro, basta rinominare i file. ..). A seconda della struttura del contratto, tutto il rischio di denaro è su di te. Sottostimato e vincerai, ma alla fine fallirai. Sovrapponi e non otterrai il contratto.

Prima regola di stima è che perderete denaro su progetti a prezzo fisso sempre.

Seconda regola di stima è che si sarà mai in grado di fornire una stima esauriente entro un margine di errore che sia accettabile per un cliente perché sarà sempre sostenere che vi mis-interpretato un requisito, che vi costerà denaro.

Il software ha requisiti soft, aspettative fluide da parte del cliente e rischi non prevedibili.

Ecco perché le metodologie Agile diventano così popolari per la creazione di software.

1. Consentono di pianificare la modifica e di rischiarla e di preventivarla.

2. Consentono al tuo cliente di essere responsabile della priorità e della direzione.

3. Permettono al cliente di avere una visione trasparente di ciò che sta costando cosa, nel bene e nel male. Il cliente acquisisce fiducia e si rapporta rapidamente se rispetti in tempo le prime iterazioni e ritieni che si tratti di uno sforzo di squadra, non di far pagare loro dei soldi.

4. Proteggi te impostando le aspettative a breve termine che il cliente può aspettarsi di vedere e il team può incontrare.

Ci sono molti altri vantaggi, se cerchi alcune delle metodologie.

Adottare i requisiti e suddividerli nei compiti più piccoli possibili. Stimare quanto tempo fare ogni attività. Più piccolo è il compito, più accurata è la stima. Poi fai il punto su cose come pause bagno, pause pranzo, tempo di malattia (tuo, mogli, bambini, cane, ecc.) E qualsiasi altra cosa che ti impedirà di lavorare.

Utilizza l'elenco delle attività come dichiarazione di lavoro. Qualunque cosa non sia nella lista, ti addebiti extra per.

Personalmente aggiungo il 30-50% alla prima stima come assicurazione.