Software Development Costi Piramide [chiusa]

Question

Un amico mi diceva l'altro giorno che non v'è una piramide per i costi di fissazione di un problema nel ciclo di vita di sviluppo del software. Dove potrei trovare questo?

Si riferiva al costo di fissazione di un problema.

Ad esempio,

  

Per risolvere un problema ai requisiti della fase Costi 1.

     

Per risolvere un problema in fase di sviluppo costa 10.

     

Per risolvere un problema in fase di test costa 100

     

Per risolvere un problema in fase di produzione costa 1000.

(Questi numeri sono solo esempi)

Mi sarebbe interessato a vedere di più su questo se qualcuno ha riferimenti.

Answer 1

L'incredibile tasso dei rendimenti decrescenti di correggere i bug del software

(Stefan Priebsh: OOP e Design Patterns: Codeworks DC nel mese di settembre 2009)

Answer 2

Questo è un risultato ben noto in ingegneria del software empirica che è stato replicato e verificato più e più volte in innumerevoli studi. Che è molto raro in ingegneria del software, purtroppo: la maggior parte di ingegneria del software "risultati" sono fondamentalmente sentito dire, aneddoti, congetture, opinioni, un pio desiderio o semplicemente bugie. In realtà, la maggior parte del software, probabilmente non merita il marchio "engineering".

Purtroppo, pur essendo uno dei suoni più solida, più scientificamente e statisticamente, più pesantemente ricercate, più ampiamente verificate, i risultati il ??più delle volte replicati dell'ingegneria del software, è anche sbagliato.

Il problema è che tutti questi studi non controllano le loro variabili in modo corretto. Se si vuole misurare l'effetto di una variabile, devi essere molto attenta ai cambiamenti solo che una variabile e che le altre variabili don 't cambiamento a tutti . Non "cambiare alcune variabili", non "minimizzare le modifiche alle altre variabili". "Solo una" e gli altri "per niente".

In alternativa, nelle brillanti parole di Zed Shaw:. Se si vuole misurare merda, non misurare altra merda

In questo caso particolare, hanno fatto non giusta misura in cui fase (requisiti, analisi, architettura, progettazione, realizzazione, collaudo, manutenzione) è stato trovato l'errore, si anche misurato come molto è rimasto nel sistema. E si scopre che la fase è praticamente irrilevante, ciò che conta è il tempo. E 'importante che i bug possono trovare veloce , non in quale fase.

Questo ha alcune implicazioni interessanti: se è importante trovare bug veloce , quindi perché aspettare così a lungo con la fase che è più probabile trovare bug: il test? Perché non mettere il test al di iniziare

Il problema con l'interpretazione "tradizionale" è che esso porta a decisioni inefficienti. Perché si assume è necessario trovare tutti i bug durante la fase di requisiti, si trascina la fase requisiti inutilmente lungo: non si può eseguire requisiti (o architetture, o disegni), in modo da trovando un bug in qualcosa che non si può nemmeno execute è freaking difficile ! In sostanza, mentre il di fissaggio bug nella fase di requisiti è a buon mercato, trovando di loro è costoso.

Se, tuttavia, si rende conto che non si tratta di trovare i bug nella prima fase di possibile , ma piuttosto di trovare gli insetti nel più breve tempo possibile , allora si può apportare modifiche al vostro processo, in modo che si sposta la fase in cui trovando bugs è più economico (testing) per il momento in cui di fissaggio loro è più economico (fin dall'inizio ).

---

Nota: Sono ben consapevole dell'ironia di finire uno sproloquio di non applicare correttamente le statistiche con una pretesa del tutto prive di fondamento. Purtroppo, ho perso il link dove ho letto questo. Glenn Vanderburg citato anche questo nel suo " Patrimonio Ingegneria del Software " parlare alla Conferenza di Lone Star Ruby 2010, ma AFAICR, lui non cita alcuna fonte, sia.

Se qualcuno sa qualsiasi fonte, si prega fatemelo sapere o modificare la mia risposta, o anche solo rubare la mia risposta. (Se si riesce a trovare una fonte, ti meriti tutto il rappresentante!)

Answer 3

vedi pagine 42 e 43 del questa presentazione (pdf).

Purtroppo la situazione è la raffigura Jörg, infatti un po 'peggio: la maggior parte dei riferimenti citati in questo sciopero documento me come fasullo, nel senso che la carta ha citato o non è una ricerca originale, o non contiene le parole a sostegno della domanda compiuti, o - nel caso del documento del 1998 su Hughes (p54) - contiene misure che infatti contraddicono ciò che è implicito nella curva P42 della presentazione: diversa forma della curva, e un modesto x5 al fattore x10 di cost-to-fix tra la fase requisiti e la fase di test funzionale (ed effettivamente diminuendo di test di sistema e manutenzione).

Answer 4

Mai sentito parlare di esso che è chiamato una piramide prima, e che sembra un po 'a testa in giù a me! Ancora, la tesi centrale è ampiamente considera corretto. solo spessore proposito, i costi di riparazione di un problema che alfa fase sono spesso banali. In fase beta potrebbe prendere un po 'più di debug utente e rapporti. Dopo la spedizione potrebbe essere molto costoso. tutta una nuova versione deve essere creato, è necessario preoccuparsi di rompere il codice in-produzione e dei dati, ci possono essere anche le vendite perse a causa del bug?

Answer 5

articolo . Si utilizza l'argomento "costo piramide" (senza nominarlo), tra gli altri.