In un post sul blog di Andrew Hay , è stato postulato il seguente assioma:
It costs significantly more to fix a bug at the end of the project that it does to fix the same bug earlier in the project.
Tuttavia, questo non sembra certo, specialmente dopo aver letto un post sul blog Meno Errato , e i dati I Ho visto che il backup è estremamente vecchio.
Questo è ancora un assioma accurato oggi?
L'unico dato difficile che abbia mai visto è Boehm e Papaccio, Capire e controllare i costi del software .
Questo risale al 1988 ed è stato uno studio di circa 80 progetti software. Hanno concluso che una decisione presa in anticipo e corretta in ritardo potrebbe costare 50-200 volte quello che avrebbe se fosse stata corretta in anticipo. Ma il tipo di decisioni molto precoci di cui stanno parlando sono quale sistema operativo su cui eseguire e quale lingua e database utilizzare.
Quindi queste cifre potrebbero essere eccessive rispetto allo sviluppo del software di oggi. Tuttavia, ora abbiamo molta esperienza nel settore e sappiamo istintivamente che è ancora vero fino a un certo punto.
All'estremo, sappiamo che se un errore nei requisiti viene catturato prima di andare in produzione, questo causa un sacco di rilavorazioni e il progetto viene ritardato o cancellato, dove se fosse stato catturato prima che qualsiasi lavoro fosse stato fatto, saremmo stati bene.
Modifica: Doc Brown fa un buon punto nel suo commento.
La ricerca di Boehm è stata condotta su progetti COBOL e FORTRAN in un momento in cui i tempi di compilazione e di esecuzione erano ridicolmente lenti. Ho iniziato la mia carriera nei primi anni '90 su COBOL e il ciclo di compilazione e test utilizzato da così tanto tempo che valeva la pena di testare a secco il codice prima di passare attraverso il ciclo (o almeno durante la fase di costruzione, nel caso in cui potresti prendere qualcosa e cancellarlo presto, risparmiando un'ora o così).
A turno, i nostri capi erano soliti ridere delle nostre lamentele perché non era tanto tempo fa che dovevano portare una scatola di schede perforate a mano nella sala server e lasciarle lì per un giorno.
Quindi era sicuramente more vero allora di quanto lo sia ora.
Eppure, molto recentemente, ho visto blog che riutilizzano la visualizzazione di questo problema di Steve McConnell ( ref , datato 1996) come se quel grafico fosse effettivamente basato su numeri rigidi. Non lo è. È una visualizzazione, per spiegare semplicemente il suo punto.
Penso che la premessa di Morendil, nell'articolo che l'OP ha citato, sia buona. La scienza che abbiamo su questo argomento è scadente e obsoleta eppure trattata come canone. Ma penso anche che regge bene e suona vero perché sappiamo per esperienza amara che è ancora vero, almeno fino a un certo punto. E penso che la sua drammatica frase "disciplina malata" non gli dia alcun favore.
Anche se non sono a conoscenza di dati rigidi o altre prove a supporto di questa affermazione, a un minimo minimo , immagino sia ragionevole.
Pensaci in questo modo .. Se hai un sistema complesso con sottosistemi interdipendenti (come fanno la maggior parte delle applicazioni non banali), pensa a problemi a sorpresa che potrebbero essere il risultato di modifiche apportate a uno qualsiasi dei sistemi. Se i sottosistemi hanno dimostrato di essere corretti (tramite test unitari e simili) e risolti in anticipo, il numero di bug che verranno causati a causa del knock-on solo viene mitigato semplicemente correggendo in anticipo.
Inoltre, se stai correggendo i bug in anticipo, l'implementazione è ancora fresca nella mente dello sviluppatore. A seconda della lunghezza di un determinato progetto, se si stanno risolvendo bug alla fine, lo sviluppatore dovrà dedicare del tempo a capire cosa hanno scritto e (forse) come funziona il sottosistema dal quale dipende il loro codice. Tempo trascorso a riapprendere questo = $.
Dubito che sia possibile trovare un modo scientificamente rigido per misurare questo - ci sono troppi altri fattori coinvolti, e non ci sono due progetti abbastanza comparabili da servire come più di casi di studio. Pensiero logico dovrebbe farti una lunga strada però. Alcuni argomenti:
Questo è materiale di base accettato dall'ingegneria dei sistemi e si applica a qualsiasi forma di sviluppo tecnico (sia che si tratti di costruire ponti, missili, navi da guerra o software).
Essenzialmente, il costo delle cose aumenta di circa un ordine di grandezza mentre ti sposti attraverso le fasi di sviluppo.
Qualcosa che costa $ 10 da fissare al punto di concepire l'idea ...
Il costo è di circa $ 100 se devi aggiornare la specifica ...
O costa circa $ 1000 se qualcosa è stato implementato ed è necessario apportare modifiche a quel punto (e aggiornare le specifiche, e ottenere le approvazioni e così via) ma non ha attraversato alcun tipo di accettazione formale / vendita test
O costano circa $ 10000 se qualcosa è stato implementato e il cliente ha accettato, e devi apportare modifiche a quel punto (e aggiornare le specifiche, ottenere le approvazioni e ri-testare e rieseguire l'accettazione e la qualifica del cliente, e così on)
E il costo dopo la distribuzione / distribuzione / messa in servizio è ancora di più.
Gli esempi abbondano e sono facili da capire: un sistema bancario con un serio cambiamento di scope fatto dopo aver utilizzato 25.000 dipendenti costerà un pacchetto in tempo di riqualificazione ... prima ancora di considerare l'ambito, la codifica, il test , regressione, ecc. ecc.
OVVIAMENTE il tuo chilometraggio può variare: i costi e gli impatti del cambiamento del sito di e-commerce di riscaldamento elettronico calzino elettronico di Fred Nurke sono in qualche modo diversi dai costi di modifica del software su un computer di controllo di volo dell'aeromobile.
Non ho accesso a dati o fatti concreti, quindi posso solo offrirti osservazioni aneddotiche raccolte nei miei ultimi 20 anni in ambito IT.
Credo che ci sia una grande differenza tra il modo in cui la maggior parte degli sviluppatori crea software oggi rispetto a 20 anni fa. Con il movimento Agile che ha acquisito così tanto slancio, in particolare negli ultimi 5-6 anni, ho assistito a un vero cambiamento di atteggiamento nei luoghi di lavoro. Tanto che la qualità di ciò che facciamo sembra crescere a passi da gigante ogni anno, e con ogni progetto applichiamo le lezioni che abbiamo imparato da un progetto all'altro. I processi più snelli combinati con un focus sullo sviluppo test-first sono cresciuti dall'essere molto controversi all'usuale. Tanto che oggi per entrare in molte aziende, se non ti senti a tuo agio con Agile, sarai fortunato se non ti mostrerà la porta.
Quindi quale impatto ha avuto questo. Prima di tutto, ho notato che i problemi spesso vengono identificati molto prima. Spesso accade che se il problema non sembra troppo grande, a volte può essere messo in attesa indefinitamente. In una rara manciata di casi, ho visto bug che si pensava fossero banali e diventavano seri problemi quando affrontati in seguito, poiché risultava evidente qualche problema fondamentale che non era considerato al momento. A volte questo può portare a un ciclo di correzione elaborato, che può essere costoso, ma spesso tale costo viene misurato meno in termini di risorse, e più spesso in termini di impatto sulla relazione tra cliente e sviluppatore. I clienti stanno crescendo abituati a questo modo di pensare agile, che restituisce loro risultati molto più velocemente di quanto non fosse ai vecchi tempi, con sprint di sviluppo altamente iterativi e rapidi tempi di risposta tra richieste e implementazione, quindi si aspettano una grande quantità di noi . E per quanto riguarda i bug attuali, il tempo di correggere un bug è più spesso notevolmente ridotto a causa di una solida serie di test per supportare le modifiche e la possibilità di creare nuovi test da cui fornire approfondimenti e soluzioni ai problemi segnalati.
Quindi, nel complesso, sembra che lo sforzo generale di correggere i bug sia stato ridotto nella maggior parte dei casi in presenza di una robusta serie di test e procedure per garantire che il testing resti al centro di ciò che lo sviluppatore fa, ma il costo effettivo è stato in qualche modo spostato, almeno in parte, dall'implementazione, ad altre aree del business, perché in qualche modo l'attenzione si è spostata dall'offerta pura e dalla domanda alla gestione delle relazioni.
Un'altra cosa che è diventata evidente, è che il nostro istinto istintivo di alcuni anni fa, che suggeriva che essere Agile avrebbe ridotto i nostri cicli di manutenzione è stato dimostrato in una misura sia giusta che sbagliata. Giusto nel senso che solidi test hanno reso più facile il debug e la correzione del nostro codice in larga misura, e per ridurre complessivamente il numero di bug rilasciati nel codice di produzione, e sbagliato nel senso che ora stiamo lavorando di più per evitare di dover mantenere il codice legacy, rinfacciando costantemente il codice e migliorando l'architettura in modo tale che diventi sempre più raro che abbiamo bisogno di sviluppare completamente nuovi prodotti da zero.
Quindi, alla fine, cosa significa questo per quanto riguarda la domanda dell'OP? Bene, significa che la risposta non è così secca come una volta pensavamo che fosse. 15 anni fa, avrei probabilmente risposto alla domanda come Sì , ma ora sento che è più realistico dire che è davvero troppo difficile misurare empiricamente, perché la natura di ciò che facciamo per sviluppare il software è cambiato molto da quando abbiamo iniziato a chiederci la domanda dell'OP a quei tempi. In un certo senso, più avanziamo le nostre tecniche e competenze come industria, più la domanda cresce da un sì definitivo, a un punto in cui sospetto che in un breve numero di anni diremo che non importa quando sistemiamo i bug, perché i nostri test e i nostri processi saranno molto più robusti, che i tempi delle correzioni dei bug saranno meno guidati dagli sforzi per risparmiare i nostri budget, e più dalle priorità per soddisfare le esigenze dei nostri clienti, e il costo relativo sarà diventare praticamente privo di significato contestualmente.
Ma come ho detto, questa non è una prova concreta supportata dai dati, solo le mie osservazioni degli ultimi anni, e il mio istinto mi dice che ci sarà più saggezza a portata di mano che migliorerà il modo in cui noi fai cose.
I bug precedenti si propagheranno ad altre parti del sistema, quindi quando correggi il bug potresti essere costretto a riscrivere alcune parti del sistema che si basavano sul bug stesso.
Accanto al tempo ti ritragheresti come sono costruite alcune parti del programma e dovrai ricordartelo. È una forma di debito tecnico (se affretti il progetto nella fase iniziale avrai problemi a finirlo a causa delle scorciatoie che hai preso).
È semplice e non c'è niente da provare.
Penso che tu stia cercando di affrettare il progetto il più velocemente possibile per presentare alcune soluzioni funzionanti al tuo dipendente. La buona notizia è che lo avrai molto velocemente, la cattiva notizia è che probabilmente non la finirai mai senza una completa riscrittura se continui a scrivere crap il più velocemente possibile e pianifichi di aggiustare tutto in un paio di mesi. Probabilmente non sarai nemmeno in grado di refactarlo.
Beh, probabilmente non posso darti la prova definitiva che stai chiedendo, ma posso riferire un incidente abbastanza recente dal mio lavoro.
Abbiamo aggiunto una funzionalità che forniva funzionalità di gestione del flusso di lavoro al nostro prodotto. Tipico materiale BDUF, specifiche firmate e approvate dal cliente. Implementato per spec. Reclami dal primo giorno sulla distribuzione.
Non abbiamo fatto una vera e propria soluzione di usabilità con il cliente, abbiamo solo preso la parola per quello che volevano. Risultato: centinaia di ore di rilavorazione: l'analisi, la progettazione, l'implementazione e il controllo qualità devono essere ripetuti. Tutto perché le specifiche mancano di particolari casi d'uso. Un bug nelle specifiche, se vuoi.
Ho visto cose simili in lavori precedenti quando qualcuno nella catena fa presupposizioni che sono diverse dalle ipotesi dell'utente finale. I bug di codifica straight-up sono relativamente facili da gestire se vengono catturati quando accadono, ma i bug di progettazione possono uccidere interi sistemi.
Se correggi il bug dopo il rilascio, allora hai il costo di trovare e correggere il bug - che potrebbe richiedere o meno tempo e costi aggiuntivi per fare il post release. Tuttavia, è necessario eseguire una serie di test di integrazione, test di regressione, test UA, attività di rilascio, ecc. A meno che la correzione del bug non venga risolta con una serie di altre correzioni o aggiornamenti della versione, si avrà una spesa aggiuntiva per le attività di test e rilascio che verrebbero evitate includendo la correzione nella versione iniziale - poiché tali costi sarebbero condivisi su un numero di correzioni / aggiornamenti / caratteristiche.
Considerate anche il costo che il bug causerà durante l'uso, se è solo cosmetico, quindi probabilmente non ha importanza, ma un bug di funzione o prestazioni potrebbe creare un costo con attività di supporto o produttività ridotta o calcoli errati.
Chiedi a Intel quanto costano il Pentium Bug, L'Ariane 5 Rocket è un altro buon esempio. Questi bug sono stati risolti alla fine del progetto. Ho lavorato su un sistema in cui un "tentativo" in una versione software ha un budget di 6 cifre. In questi casi estremi, è facile vedere il costo. In altri (più?) Casi, il costo viene nascosto dal rumore, ma è ancora lì.
Non c'è dubbio che gli insetti costano soldi mentre esistono. Un articolo, i rapporti sui difetti, richiedono tempo per la compilazione, il triage e la chiusura in dup, il tempo è denaro, quindi un bug aperto crea costi continui. pertanto, è necessario che il rimedio dei bug risolva i costi più che risolverli prima.
Se un bug sfugge allo stato selvatico, il costo ha un salto da punto ...... È "La fine del progetto" prima o dopo il rilascio del software?
Una volta ho letto un articolo che aveva due punti interessanti (sfortunatamente i riferimenti che ho avuto sono ormai lontani, quindi dovrò postulare solo qui). Il primo punto che hanno fatto è stato che circa il 50% di tutti gli errori sono stati introdotti nella specifica dei requisiti e che circa il 90% di tutti gli errori sono stati rilevati durante i test UAT o di sistema.
Il secondo punto era che per ogni fase del modello V il costo era aumentato di 10 volte. Indipendentemente dal fatto che il fattore sia corretto, trovo un po 'irrilevante, ma gli errori più costosi sono quando il tuo progetto si basa su un'ipotesi errata. Questo porta a una grande quantità di riscrittura. Tutto il codice che funziona a causa di quell'ipotesi, ma fallisce quando viene applicata la supposizione corretta, dovrà essere riscritto.
Ho sperimentato che l'intero modello di dominio deve essere riscritto a causa di un'assunzione errata nelle specifiche dei requisiti. Se un tale errore viene rilevato precocemente, ovvero quando si esaminano le specifiche dei requisiti, il costo è molto basso. In questo caso particolare avrebbe preso dieci righe di testo. Nel caso in cui sia stato trovato durante UAT (come questo) il costo è sostanziale (nell'esempio riportato il costo del progetto è stato aumentato del 50%)
Nessun dato statistico, ma esperienza personale:
Il codice di controllo del motore del razzo su cui stavo lavorando aveva una riga come powerCutoff = someCondition && debugOptions.cutoffIsAllowed; . L'opzione predefinita non consentiva alcun taglio. La build 'final' doveva rimuovere tutte le opzioni di debug, quindi la riga è stata modificata in powerCutoff = someCondition; .
Hai individuato il bug durante la revisione del codice? Non l'abbiamo fatto. La prima volta che la condizione di innesco si è verificata durante il test causando un taglio imprevisto era solo pochi mesi prima del primo volo.
Questo bug sarebbe costato meno di un'ora se fosse stato catturato durante la revisione. Potrebbe essere costato un giorno o due se è stato catturato durante l'integrazione, causando una singola ripetizione del test. Se è stato catturato durante la qualifica formale, potrebbe costare una settimana o due provocando il riavvio di una serie di test completa con una nuova build.
Come era, il costo era in crisi. Per prima cosa abbiamo progettato e fatto dei test per determinare se l'unità di volo potesse persino attivare la condizione. Dopo che è stata determinata per essere una possibilità reale, c'erano costi per l'ingegnerizzazione, la gestione e l'analisi dei clienti della soluzione migliore, il rilascio della nuova build, la creazione e l'esecuzione di un nuovo piano di test di regressione, test di sistema in più unità e simulatori. Tutto sommato costava migliaia se non decine di migliaia di ore uomo. Inoltre i 15 minuti originali per apportare effettivamente il codice giusto.
Purtroppo, come molte cose, dipende.
Se un messaggio di dialogo è errato, potrebbe essere "banale" risolvere (aggiornare string, ricostruire / pacchettizzare, ridistribuire). O se è necessario aggiornare un layout, una modifica a un file .css potrebbe essere sufficiente.
Se il bug è che l'output di un metodo critico che ha una specifica di oltre 100 pagine e che la dimostrazione è errata, l'indagine stessa potrebbe richiedere ore o giorni. Questo è ciò a cui si riferisce il vecchio "assioma" e ciò che, tra l'altro, TDD e agile sta cercando di evitare (fallire presto e chiaramente, fare progressi incrementali sicuri, yada).
Dalla mia recente esperienza con i team multi-scrum su un singolo progetto, i "bug" sono in genere problemi di fusione / integrazione che vengono visualizzati solo alla fine di un rilascio, in quanto i rami di funzionalità vengono promossi come stabili. Questi sono i peggiori, poiché i conflitti spesso richiedono il supporto di squadra trasversale mentre le squadre sono in una raffica per completare i propri obiettivi, ma non so che sono più costosi di altri bug, come si verificano quando si verificano: in ritardo il rilascio, ma al più presto possibile. Questo è ciò che li rende peggiori.
Leggi altre domande sui tag debugging project-management cost-estimation
