Quali ipotesi / dichiarazioni di non responsabilità dovrebbero essere incluse con una stima del software?

what common assumptions do you include with your estimates

Ogni singolo "fatto" fornito dal cliente è elencato come presupposto.

Queste sono le ipotesi comuni.

Tutto il resto è solo fluff. Puoi scrivere un sacco di cose morbide come se tu credessi che la pestilenza non si scateni, e che gli zombi non sorgano e mangiano il nostro cervello, ma niente ha senso per un cliente.

Prendendo i loro "fatti" sullo sforzo di sviluppo, e rielaborando ogni "fatto" come presupposto chiarisce che tutto è fantasioso.

Poi.

Studia i metodi Agile e assicurati di identificare che - in realtà - è una questione di priorità e budget. Costruirai le cose dal più importante al meno importante e ti potranno fermare in qualsiasi momento.

Ci sono diversi - inconciliabilmente diversi - "intenti" per una stima.

1. Potrebbe essere un prezzo fisso e fisso che stabilirà un limite superiore per il budget e un limite inferiore per la funzionalità consegnata.

2. Potrebbe essere un prezzo di riferimento utilizzato per decodificare una tariffa oraria utilizzata per qualificarti come risorsa.

3. Potrebbe essere un numero di costo che prende una decisione in termini di costi / benefici.

Finché non saprai cosa è l'"intento", la natura delle ipotesi cambierà. Non esiste un'unica risposta corretta finché non definisci l'intento del cliente

1. Accetta requisiti specifici chiari con il cliente.
2. Concorda su ciò che costituisce il soddisfacimento di ogni requisito, in un modo che sia chiaro, misurabile e non ambiguo (vale a dire che superi un test di accettazione).
3. Come parte del processo di stima interna, suddividere tutto il lavoro richiesto in attività secondarie più piccole. Continuate a farlo finché non avrete compiti abbastanza piccoli da poter stimare con precisione. Sommare tutte le stime più piccole per una stima totale di tempo e denaro. Assicurati di includere il tempo necessario per scrivere test unitari, test di accettazione e refactoring.
4. Aggiungi almeno il 20% di padding al calcolo della stima temporale risultante.
5. Spiega chiaramente che il lavoro che va oltre lo scopo n. 2 non fa parte del preventivo e avrà un costo extra.

Beh, la maggior parte dei clienti vedrà una stima con una serie di disclaimer come una stima da parte di Moses stesso e un po 'di rumore irrilevante, ma posso darti alcuni suggerimenti (e sono sicuro che ci sono molti legali che io indosso ne so qualcosa):

1. Si presume che il cliente ti fornirà ciò di cui hai bisogno, a seconda del progetto. Se non sono in grado di rispondere prontamente alle tue domande, fornisci l'accesso alla rete, il sistema di test, i dati di test necessari - qualunque sia, quindi almeno la schedulazione è colpa loro.

2. Bene, ovviamente hai qualche accordo sul lavoro che stai facendo per quella stima. Supponi che il lavoro non venga modificato o aggiunto a

3. Si presume che il prodotto non sia privo di bug. Se supera i test di accettazione concordati, allora hai finito.

4. Se ci sono immagini o modelli, si presume che non richiedano che il prodotto assomigli esattamente a quelle immagini o ai modelli.

5. Quando hai stimato che c'erano probabilmente molte ipotesi specifiche per il progetto che dovevano essere enunciate. Come gli elementi dell'interfaccia utente, verranno estratti dalla libreria standard .NET e non dovranno essere personalizzati o utilizzati al di fuori degli usi standard del settore per il progetto.

Che dire di una stima è un'approssimazione e non può essere del tutto accurata?

O che dire della gamma di errori +% 150 / -% 10? : P

Ci sono state diverse domande su questo sito sulla consegna del codice e sul mancato pagamento. Spiega chiaramente che possono assumere se non ti pagano, il codice non verrà consegnato in un formato utilizzabile. Qualsiasi tentativo di utilizzare il codice senza pagamento è una violazione del contratto. Dovresti essere in anticipo su qualsiasi tecnologia che pianifichi di implementare per raggiungere questo obiettivo.

Gli altri dettagli possono derivare da un accordo standard o da qualunque cosa il cliente ti consenta di farla franca.

La migliore ipotesi è, supponiamo che la stima sia lontana. Lo sviluppo del software è troppo complicato per stimare più di due o tre settimane. Almeno, se stai creando qualcosa di nuovo.

Se stai valutando di fare in modo che il tuo sito web 100esimo si trovi sullo stesso modello, forse puoi estenderlo un po '.

Va da sé che dovrebbero firmare una Limitazione di responsabilità ... non si vuole essere in una situazione in cui si rischiano potenzialmente milioni di dollari di danni a causa di "profitti persi" o "danni conseguenti" in scambio per un progetto $ 5000.