Debug di fatti e statistiche [chiuso]

In Rapid Development: Taming Wild Software Schedules, Steve McConnell cita alcuni articoli di Capers Jones, Barry Boehm, Thomas Glib e Philip Papaccio. Alcune delle figure di riferimento sono:

1. Rielaborare i difetti nei requisiti, nella progettazione e nel codice consuma il 40-50% del costo totale dello sviluppo del software. (Boehm, Barry W. 1987. "Migliorare la produttività del software." IEEE Computer, settembre: 43-57 .; Jones, Capperi, ed. 1986. Tutorial: Programmazione Produttività: Problemi per gli anni Ottanta, 2a ed. Los Angeles: IEEE Computer Society Press.)

2. Ogni ora spesa per la prevenzione dei difetti ridurrà i tempi di riparazione di 3-10 ore. (Jones, Capers, 1994. Valutazione e controllo dei rischi software: Cliffs Englewood, NJ: Yourdon Press.)

3. Rielaborare un problema con i requisiti una volta che il software è stato spedito costa 50-200 volte ciò che sarebbe necessario per rielaborare durante i requisiti. (Boehm, Barry W. e Philip N. Papaccio. 1988. "Comprensione e controllo dei costi del software." Transazioni IEEE in Ingegneria del software, 14, 10 (ottobre): 1462-1477.)

4. Il 60% di tutti i difetti di solito esiste in fase di progettazione. (Glib, Tom, 1988. Principi di gestione dell'ingegneria del software: Wokingham, Inghilterra: Addison-Wesley.)

Alcune di queste fonti si occupano di una differenza nel tempo. Non ho prove concrete a sostegno di ciò (potrebbe essere sui giornali), ma sospetto che una buona parte del costo totale stia pagando gli sviluppatori per il loro tempo, quindi usare il tempo o il costo sarebbe un confronto valido dal punto di vista della gestione del progetto. Suggerirei di leggere i documenti, però.

Non ci sono ancora molte ricerche su questo argomento. Joel e Jeff ne parlano nel Podcast di Stack Exchange, Episodio # 09 . Il loro ospite è un ragazzo che ha fatto qualche studio qui, e sta anche spingendo ad applicare più tecniche di ingegneria rigida all'ingegneria del software.

Quindi, la risposta è, come hai scoperto, non c'è ancora molta ricerca, ma quell'episodio di podcast può indicarti altre persone e risorse che stanno davvero iniziando a fare questa domanda.

La domanda si rivolge a così tanti sviluppatori, lingue, diversi livelli di abilità, lavori e attività - hai bisogno di un numero molto grande, di far entrare tutti, e quindi forse non si adatta a questa lingua o quella, per sviluppatori maturi o principianti . Quindi, per costruire la propria statistica: avere un allarme casuale una volta al giorno e annotare quale attività si stava eseguendo, quando l'allarme si è spento. Dopo 100 allarmi, hai una stima approssimativa che potrebbe non funzionare per gli altri, ma per te.