Premetto questo con il fatto che la maggior parte di ciò che trovo proviene dagli anni '70 e dai primi anni '80. Durante questo periodo, i modelli di processo sequenziali erano molto più comuni degli approcci iterativi e / o incrementali (il modello a spirale o i metodi agili). Gran parte di questo lavoro è basato su questi modelli sequenziali. Tuttavia, non penso che ciò distrugga la relazione, ma uno dei vantaggi degli approcci iterativi / incrementali è il rilascio rapido di funzionalità (un'intera porzione verticale di un'applicazione) e la correzione dei problemi prima che le dipendenze vengano iniettate e la complessità di ogni fase è alto.
Ho appena estratto la mia copia di Software Engineering Economics e ho trovato un riferimento ai dati alla base di questo grafico nel Capitolo 4. Cita "Ispezioni di progettazione e codice per ridurre gli errori nello sviluppo del programma" di ME Fagan ( IEEE , PDF da UMD ), EB "Gestione dell'ingegneria del software" di Daly, "Un'analisi delle risorse utilizzate nello sviluppo del software di sistema di salvaguardia" ( ACM ) di WE Stephenson e "diversi progetti TRW".
... il costo relativo della correzione degli errori del software (o di apportare altre modifiche al software) in funzione della fase in cui vengono apportate le correzioni o le modifiche. Se viene rilevato e corretto un errore dei requisiti software durante la fase dei piani e dei requisiti, la sua correzione è una questione relativamente semplice di aggiornamento delle specifiche dei requisiti. Se lo stesso errore non viene corretto fino alla fase di manutenzione, la correzione comporta un inventario molto più ampio di specifiche, codice, manuali dell'utente e di manutenzione e materiale di formazione.
Inoltre, le correzioni tardive comportano un processo di approvazione e controllo delle modifiche molto più formale e un'attività molto più ampia per riconvalidare la correzione. Questi fattori si combinano per rendere l'errore in genere 100 volte più costoso da correggere nella fase di manutenzione su grandi progetti rispetto alla fase dei requisiti.
Bohem ha anche esaminato due progetti più piccoli e meno formali e ha riscontrato un aumento dei costi, ma molto meno significativo delle 100 volte identificate nei progetti più grandi. Dato il grafico, le differenze sembrano essere 4 volte maggiori per correggere un difetto dei requisiti dopo che il sistema è operativo rispetto alla fase dei requisiti. Lo ha attribuito al più piccolo inventario di articoli che compongono il progetto e alla ridotta formalità che ha portato alla possibilità di implementare più velocemente riparazioni più semplici.
Basato su Boehm in Software Engineering Economics, la tabella in Code Complete è piuttosto gonfia (la fascia bassa delle gamme è spesso troppo alta). Il costo per apportare qualsiasi modifica all'interno della fase è effettivamente 1. Estrapolando dalla Figura 4-2 in Economia dell'ingegneria del software, una modifica dei requisiti dovrebbe essere 1,5-2,5 volte nell'architettura, 2,5-10 nella codifica, 4-20 nei test e 4- 100 in manutenzione. L'importo dipende dalle dimensioni e dalla complessità del progetto, nonché dalla formalità del processo utilizzato.
Nell'appendice E di Barry Boehm e l' agilità e la disciplina di bilanciamento di Richard Turner contiene una piccola sezione sui risultati empirici relativi al costo del cambiamento.
I paragrafi iniziali citano la Extreme Programming Explained di Kent Beck, citando Beck. Dice che se il costo delle modifiche aumentasse lentamente nel tempo, le decisioni verrebbero prese il più tardi possibile e verrebbe implementato solo ciò che era necessario. Questa è nota come "curva piatta" ed è ciò che guida la programmazione estrema. Tuttavia, ciò che la letteratura precedente aveva scoperto era la "curva ripida", con sistemi piccoli (<5 KSLOC) con un cambio di 5: 1 e sistemi grandi con un cambio di 100: 1.
La sezione cita il Center for Empirically Based Software Engineering dell'Università del Maryland (sponsorizzato dalla National Science Foundation). Hanno eseguito una ricerca della letteratura disponibile e hanno scoperto che i risultati tendevano a confermare un rapporto 100: 1, con alcuni risultati che indicano un intervallo da 70: 1 a 125: 1. Sfortunatamente, si trattava in genere di progetti "big design up front" e gestiti in modo sequenziale.
Esistono esempi di "piccoli progetti Java commerciali" eseguiti utilizzando Extreme Programming. Per ogni storia, è stata tracciata la quantità di sforzo nel correggere gli errori, nel nuovo design e nel refactoring. I dati mostrano che man mano che il sistema viene sviluppato (vengono implementate più storie utente), lo sforzo medio tende ad aumentare a un ritmo non banale. Lo sforzo nel refactoring aumenta di circa il 5% e gli sforzi verso la fissazione dello sforzo aumentano di circa il 4%.
Quello che sto imparando è che la complessità del sistema gioca un ruolo importante nella quantità di sforzo necessario. Costruendo sezioni verticali attraverso il sistema, rallenti la velocità della curva aggiungendo lentamente complessità invece di aggiungerla in pile. Piuttosto che affrontare la massa di complessità dei requisiti seguita da un'architettura estremamente complessa, seguita da un'implementazione estremamente complessa e così via, si inizia in modo molto semplice e si aggiunge.
Che impatto ha questo sul costo da riparare? Alla fine, forse non molto. Tuttavia, ha i vantaggi di consentire un maggiore controllo sulla complessità (attraverso la gestione del debito tecnico). Inoltre, i risultati frequenti spesso associati all'agile significano che il progetto potrebbe concludersi prima - anziché consegnare "il sistema", i pezzi vengono consegnati fino a quando le esigenze aziendali non vengono soddisfatte o non cambiano drasticamente un nuovo sistema (e quindi un nuovo progetto) è necessario.
Le metriche e i modelli di Stephen Kan nell'ingegneria della qualità del software hanno una sezione nel capitolo 6 sull'efficacia in termini di costi della rimozione dei difetti di fase.
Comincia citando il documento di Fagan del 1976 (citato anche in Software Engineering Economics) per affermare che le rilavorazioni fatte nella progettazione di alto livello (architettura di sistema), nella progettazione di basso livello (progettazione dettagliata) e l'implementazione possono essere tra 10 e 100 volte meno costose del lavoro svolto durante i test a livello di componenti e sistemi.
Cita anche due pubblicazioni, del 1982 e del 1984, di Freedman e Weinberg che parlano di sistemi di grandi dimensioni. Il primo è "Manuale di procedure dettagliate, ispezioni e recensioni tecniche" e il secondo è "Recensioni, procedure dettagliate e ispezioni". L'applicazione delle revisioni all'inizio del ciclo di sviluppo può ridurre il numero di errori che raggiungono le fasi di test di un fattore di 10. Questa riduzione del numero di difetti porta a ridurre i costi dei test dal 50% all'80%. Dovrei leggere gli studi in modo più dettagliato, ma sembra che il costo includa anche la ricerca e la correzione dei difetti.
Uno studio del 1983 di Remus, "Convalida del software integrata nella vista delle ispezioni / revisioni", ha studiato il costo della rimozione dei difetti in diverse fasi, in particolare ispezioni, test e manutenzione di progettazione / codice, utilizzando i dati del laboratorio IBM Santa Teresa in California. I risultati citati indicano un rapporto di costo di 1:20:82. Cioè, un difetto riscontrato nelle ispezioni di progettazione o di codice ha un costo per la modifica di 1. Se lo stesso difetto sfugge ai test, costerà 20 volte di più. Se sfugge fino a un utente, moltiplica il costo per correggere fino a 82. Kan, utilizzando i dati di esempio della struttura di Rochester, Minnessota di IBM, ha riscontrato che il costo di rimozione dei difetti per il progetto AS / 400 era simile alle 1:13:92. Tuttavia, sottolinea che l'aumento dei costi potrebbe essere dovuto alla maggiore difficoltà a trovare un difetto.
Le pubblicazioni di Gilb del 1993 ( "Ispezione del software" ) e del 1999 ("Ottimizzazione delle specifiche di ingegneria del software e dei processi di controllo della qualità") sull'ispezione del software sono citate per corroborare gli altri studi.
Ulteriori informazioni sono disponibili nella pagina di Construx sull'aumento del costo dei difetti , che fornisce una serie di riferimenti sull'aumento dei costi di riparazione dei difetti. Va notato che Steve McConnell, autore di Code Complete, ha fondato e lavora per Construx.
Di recente ho ascoltato un discorso, Real Software Engineering , tenuto da Glenn Vanderburg alla Lone Star Ruby Conference nel 2010. Ha tenuto lo stesso discorso alla Scottish Ruby Conference e Erubycon nel 2011, QCon San Francisco nel 2012 e O'Reilly Software Architecture Conference nel 2015 . Ho ascoltato solo la Conferenza sul rubino della stella solitaria, ma il discorso si è evoluto nel tempo man mano che le sue idee venivano perfezionate.
Venderburg suggerisce che tutti questi dati storici stanno effettivamente mostrando il costo per correggere i difetti col passare del tempo, non necessariamente mentre un progetto si muove attraverso le fasi. Molti dei progetti esaminati nei documenti e nei libri precedentemente menzionati erano progetti sequenziali "a cascata", in cui fase e tempo si muovevano insieme. Tuttavia, un modello simile emergerebbe in progetti iterativi e incrementali: se un difetto fosse iniettato in una iterazione, sarebbe relativamente poco costoso da correggere in quella iterazione. Tuttavia, con il progredire delle iterazioni, accadono molte cose: il software diventa più complesso, le persone dimenticano alcuni dei dettagli minori sull'uso di particolari moduli o parti del codice, i requisiti cambiano. Tutto ciò aumenterà il costo della correzione del difetto.
Penso che questo sia probabilmente più vicino alla realtà. In un progetto a cascata, il costo aumenta a causa della quantità di artefatti che devono essere corretti a causa di un problema a monte. Nei progetti iterativi e incrementali, il costo aumenta a causa di un aumento della complessità del software.