La metodologia di test del software si basa su dati errati?


45

È un fatto ben noto nell'ingegneria del software che il costo della correzione di un bug aumenta esponenzialmente in seguito allo sviluppo del bug. Ciò è supportato dai dati pubblicati in Code Complete e adattati in numerose altre pubblicazioni.

Tuttavia, risulta che questi dati non sono mai esistiti . I dati citati da Code Complete apparentemente non mostrano una tale correlazione costo / tempo di sviluppo e tabelle pubblicate simili hanno mostrato solo la correlazione in alcuni casi speciali e una curva piatta in altri (cioè nessun aumento dei costi).

Esistono dati indipendenti per confermare o confutare questo?

E se vero (cioè se semplicemente non ci sono dati per supportare questo costo esponenzialmente più elevato per i bug scoperti in ritardo), che impatto ha sulla metodologia di sviluppo del software?


Sembra logico, poiché la scoperta di bug in seguito nella maggior parte dei casi comporta anche la corruzione dei dati. Inoltre, avere dati danneggiati costa molto alle aziende se questo verrà scoperto in seguito nel processo di correzione del bug.
EL Yusubov,

8
@ElYusubov Lo fa davvero. Ma il buon senso può essere molto ingannevole. Le nostre menti sono facilmente ingannate dalla logica apparente quando in realtà è il contrario. Ecco perché l'ingegneria del software basata sull'evidenza è così importante.
Konrad Rudolph,


2
Per la cronaca (e menzionato nella mia risposta), la prima menzione di questo che ho potuto trovare è ben prima di Code Complete. Il lavoro di Fagan e Stephenson (in modo indipendente) nel 1976 è il primo riferimento a ciò che posso trovare. La prima edizione di Code Complete non fu pubblicata fino al 1993, quasi 20 anni dopo. Mi aspetto che il lavoro di Barry Boehm negli anni '80 abbia portato all'aumento della popolarità di questa idea: il lavoro di Boehm ha influenzato molto il processo di ingegneria del software negli anni '80 e fino alla fine degli anni 2000.
Thomas Owens

1
È assiomatico che qualsiasi affermazione sulle statistiche di ingegneria del software sia errata, compresa questa. (I bug che trovi in ​​seguito sono generalmente i bug più complessi. E risolverli è più complicato dai "controlli" messi in atto con correzioni a termine.)
Daniel R Hicks,

Risposte:


25

La metodologia di test del software si basa su dati errati?

Sì, in modo dimostrabile. L'esame della curva del costo del cambiamento agile mostra che parte del lavoro di Kent Beck su XP (non sono sicuro che fosse parte della sua motivazione o della sua giustificazione) consisteva nel "appiattire la curva" dei costi dei difetti, in base alla conoscenza del " "curva esponenziale che si trova dietro la tabella Codice completo. Quindi sì, lavorare su almeno una metodologia - quella che ha fatto di più per diffondere lo sviluppo del primo test - è almeno in parte basata su dati errati.

Esistono dati indipendenti per confermare o confutare questo?

Sì, ci sono sicuramente altri dati che puoi consultare: lo studio più grande di cui sono a conoscenza è l'analisi dei difetti effettuata su Hughes Aircraft nell'ambito del loro programma di valutazione CMM . Il rapporto da lì mostra come i costi dei difetti dipendevano dalla fase per loro : sebbene i dati in quel rapporto non includano variazioni, quindi devi stare attento a trarre troppe conclusioni "questa cosa costa più di quella cosa". Dovresti anche notare che, indipendentemente dalla metodologia, ci sono stati cambiamenti negli strumenti e nelle tecniche tra gli anni '80 e oggi che mettono in discussione la rilevanza di questi dati.

Quindi, supponendo che abbiamo ancora un problema a giustificare questi numeri:

che impatto ha questa metodologia sullo sviluppo del software?

Il fatto che abbiamo fatto affidamento su numeri che non possono essere verificati non ha impedito alle persone di progredire sulla base di aneddoti ed esperienze: allo stesso modo in cui vengono appresi molti mestieri da apprendista. Non credo che ci fosse un Journal of Evidence-based Masonry durante il Medioevo, ma un intero gruppo di edifici grandi, imponenti e di lunga durata sono stati comunque costruiti con un discreto successo. Ciò significa che basiamo principalmente la nostra pratica su "cosa ha funzionato per me o per le persone che ho incontrato"; niente male, ma forse non è il modo più efficiente per migliorare un campo di milioni di persone che forniscono la pietra angolare dell'attuale era tecnologica.

Trovo deludente che in una cosiddetta disciplina ingegneristica non abbia basi migliori nell'empirismo, e sospetto (anche se chiaramente non posso dimostrare) che saremmo in grado di fare progressi migliori e più chiari nel migliorare le nostre tecniche e metodologie quel fondamento in atto - proprio come sembra che la medicina clinica sia stata trasformata dalla pratica basata sull'evidenza. Questo si basa su alcuni grandi presupposti:

  • che la natura proprietaria della maggior parte delle pratiche di ingegneria del software non impedisce la raccolta di dati utili e pertinenti sufficienti;
  • che le conclusioni tratte da questi dati sono generalmente applicabili (poiché l'ingegneria del software è una professione qualificata, le variazioni personali di esperienza, capacità e gusto potrebbero influenzare tale applicabilità);
  • che gli ingegneri del software "sul campo" sono in grado e motivati ​​a utilizzare i risultati così ottenuti; e
  • che in realtà sappiamo quali domande dovremmo porre in primo luogo. Questo è ovviamente il punto più importante qui: quando parliamo di migliorare l'ingegneria del software, che cosa vogliamo migliorare? Qual è la misura? Il miglioramento di tale misurazione migliora effettivamente il risultato o gioca il sistema? Ad esempio, supponiamo che il management della mia azienda abbia deciso di ridurre il rapporto tra costo effettivo del progetto e costo previsto del progetto. Potrei semplicemente iniziare a moltiplicare tutte le mie stime dei costi per un fattore di fondente e raggiungerei questo "obiettivo". Dovrebbe quindi diventare una pratica industriale standard per confondere tutte le stime?

Meta-risposta straordinaria sull'ingegneria basata sull'evidenza. Grazie.
Konrad Rudolph,

4
Accidenti, ho appena capito che questo proviene direttamente dalla bocca del cavallo. Hehe. Eccezionale.
Konrad Rudolph,

1
Ho la sensazione che tutti stiano interpretando l'uso di "dati imperfetti" come "completamente falso, è vero il contrario", ma ho la sensazione che la tua posizione sia semplicemente quella di sottolineare che potrebbe essere falso. È corretto?
Daniel B,

3
@DanielB Corretto. Mostrami le prove che in realtà è sbagliato e potrei cambiare idea; fino ad allora so solo che non è evidentemente giusto.

1
@GrahamLee Vedo il tuo punto (basti pensare che il fraseggio potrebbe essere stato un po 'inutilmente aggressivo). Per curiosità, ho trovato qui il documento di Fagan , che dice "... consente la rilavorazione ... vicino alla loro origine ... da 10 a 100 volte meno costosa rispetto a se fosse eseguita nell'ultima metà del processo". Non vedo citazioni vicino a questo testo però.
Daniel B,

8

Da parte mia, la risposta a "come influisce questa metodologia di sviluppo del software" è "non molto".

Indipendentemente dal fatto che sia stato sviluppato dallo sviluppatore o dall'utente finale, sia che occorra più denaro per risolverlo dopo che è stato rilevato dall'utente o meno, resta il fatto che è stato trovato un bug nel sistema. Se catturato dallo sviluppatore, si spera che sia una soluzione rapida. La stessa speranza vale per i bug catturati dall'utente.

Indipendentemente dal costo effettivo dell'ora dello sviluppatore per correggere un bug rilevato da un utente finale, c'è il costo immateriale di mantenere lo stereotipo che i programmatori fanno schifo in quello che fanno. Quando un utente trova un bug, è colpa dello sviluppatore. Pertanto, ogni errore rilevato dall'utente finale riduce la fiducia dell'utente nel sistema. È come visitare una casa che vuoi comprare e vedere una macchia d'acqua che appare attraverso il soffitto in un angolo della casa. Questo, di per sé, è una soluzione semplice, ma ti chiedi cosa l'abbia causata e cos'altro possa aver influito su quella causa principale. Quanto vale la tua tranquillità? Potrebbe essere necessario abbattere i muri alle borchie e ispezionare visivamente tutto per assicurarsi che la macchia provenisse da un incidente isolato che è stato riparato. Sapere che potrebbe essere una possibilità non ti rende molto fiducioso in casa. Allo stesso modo,

Questi costi immateriali vengono evitati prima che il bug venga scoperto, che è lo scopo dichiarato delle metodologie di tipo TDD. Un bug rilevato durante la digitazione dallo sviluppatore o dal partner in una coppia, uno rilevato al momento della compilazione o uno rilevato dal test di unità / integrazione (il livello aggiunto da TDD), è un bug che l'utente non deve mai sapere, che il tuo il project manager non deve mai scusarsi e non devi essere sottratto a tutto ciò che stai facendo proprio in questo secondo per cambiare marcia in modalità di correzione dei difetti su una parte del sistema che pensavi di esserti lasciato alle spalle settimane fa.


3
Risposta interessante. Cerco di far capire ai miei utenti che lo sviluppo è un processo iterativo o sia perfezionamento che miglioramento. Posso dare loro qualcosa molto rapidamente, e se trovano problemi o vogliono miglioramenti posso anche cambiare questi cambiamenti molto rapidamente (minuti o ore, non giorni o settimane). Il sistema diventa più stabile nel tempo, ma si fidano del processo di sviluppo e del risultato finale, piuttosto che del processo di specifica e della prima build. (ovviamente dipende dall'ambiente in cui lavori: sto scrivendo app line of business, quindi se si rompono, vengono riparate).
Kirk Broadhurst,

Sfortunatamente, l'evidenza originale - che gli errori dei requisiti rilevati quando il prodotto è messo in campo sono più costosi degli errori di implementazione rilevati quando il prodotto è messo in campo - implica la necessità di una migliore convalida, non di una migliore verifica. TDD - utilizzando i test per verificare il prodotto rispetto ai requisiti - semplicemente non è rilevante per trovare questi bug.
Pete Kirkham,

6

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.


@AndresF. uno dei problemi che ho riscontrato nel rintracciare queste citazioni è quello che Bossavit ha descritto come il problema "ago in un pagliaio" nel libro a cui ti sei collegato. Citare un libro è una grande offuscamento - anche se è ancora in stampa quando vai a leggere la citazione, hai alcune centinaia di pagine da leggere cercando la piccola pepita che sostiene l'affermazione dell'autore citante.

3

È solo una logica semplice.

Errore rilevato nella specifica.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Come puoi vedere più tardi viene rilevato l'errore, più persone sono coinvolte, più lavoro deve essere ripetuto e in qualsiasi ambiente "normale" il lavoro di ufficio e la burocrazia aumentano esponenzialmente una volta colpito l'UAT.

Tutto ciò senza includere i costi che un'azienda potrebbe sostenere a causa di un errore nel software di produzione (vendite perse, ordini eccessivi, hacking dei clienti ecc. Ecc.)

Non credo che nessuno sia mai riuscito a scrivere un sistema non banale che non abbia mai avuto bug in produzione, ma qualsiasi cosa che puoi fare per catturare i bug in anticipo ti farà risparmiare tempo e fatica a lungo termine. Revisioni delle specifiche, revisioni del codice, test approfonditi dell'unità, utilizzo di programmatori diversi per scrivere i test, ecc. Ecc. Sono tutti metodi collaudati per la cattura precoce dei bug.


2
Questo riguarda solo un caso: errore rilevato nelle specifiche, ovvero un errore introdotto all'inizio. Ma gli errori possono essere introdotti in tutte le fasi dello sviluppo (incluso il bug fix post-deployment) e correggere tali errori sarà notevolmente più semplice perché probabilmente influenzeranno una parte più piccola del sistema.
Konrad Rudolph,

2
Ma il problema è che le correzioni di bug possono avere effetti collaterali imprevisti, quindi a meno che tu non possa assolutamente garantire che la correzione interesserà solo un particolare sottoinsieme di componenti, sei bloccato con la ripetizione di SIT UAT ecc. Inoltre, la traccia di carta rimane ugualmente onerosa, non importa quanto piccola sia modificare.
James Anderson,

2
Non sono ancora convinto che ciò dimostri che i bug saranno sempre più costosi da correggere se scoperti in ritardo. Direi che un bug diventa più costoso da correggere con il passare del tempo dopo la sua introduzione . Vale a dire un bug introdotto in ritardo, scoperto subito dopo e risolto è più economico di un bug introdotto molto presto e scoperto presto (ma con un ritardo più lungo rispetto al primo caso). Almeno potrei immaginare che funziona così.
Konrad Rudolph,

@KonradRudolph Potresti elaborare? Anche questo post è praticamente la mia comprensione, e non vedo perché il tempo sia importante, ma la fase no. Per me, la misura del tempo in un progetto è la tua fase corrente (e talvolta la tua iterazione timebox per passare attraverso tutte le fasi). Non vedo la differenza tra il lavoro svolto nel Giorno 3 della progettazione dettagliata e il Giorno 300: il prodotto di progettazione dettagliata non è stato utilizzato per realizzare altri prodotti di lavoro, quindi un difetto iniettato nella progettazione dettagliata esiste solo in un posto e solo richiede un cambiamento lì. Non vedo quanto sia importante il passare dei giorni.
Thomas Owens

3
@Thomas, sto solo ipotizzando. Ma il tempo è importante perché la maggior parte delle funzioni di codice o specifiche introdotte influenzerà più componenti con il passare del tempo, a meno che non siano altamente specializzati e nient'altro dipenderà mai da essi, né direttamente né indirettamente. Quindi un bug che esiste da molto tempo, indipendentemente dalla fase in cui è stato introdotto, influenzerà potenzialmente molte parti del sistema e la sua rimozione richiede di assicurarsi che nessun altro componente venga interrotto da quel processo.
Konrad Rudolph,

2

Credo che questo sia, ed è sempre stato, relativo alla gestione del rischio e all'economia. Qual è il costo per ridurre il numero di difetti rispetto al valore attuale dell'impatto di futuri difetti. La traiettoria dell'uccello giallo che si stacca leggermente in Angry Birds non equivale alla traiettoria di un missile da crociera Tomahawk spento. Gli sviluppatori di software in entrambi i progetti non possono prendere decisioni sulla base di quella tabella. A questo proposito, nulla cambia.

Il modo in cui penso che tende a funzionare è attraverso il feedback, i bug costosi sul campo fanno sì che le aziende restringano i loro processi di qualità, mentre nessuna lamentela da parte del settore provoca il rilassamento delle aziende. Quindi, nel tempo, le società di sviluppo software tenderanno a convergere o oscillare attorno a qualcosa che funziona per loro (+/-). Il codice completo può influenzare alcuni valori iniziali o trascinare leggermente le aziende in un modo o nell'altro. Un'azienda che spende troppi sforzi per rimuovere i difetti che nessuno noterebbe probabilmente perderà affari con un concorrente che ha un approccio più ottimizzato. D'altra parte, anche una società che rilascia prodotti difettosi andrà fuori mercato.

Alcuni articoli pertinenti da una rapida ricerca (leggi gli articoli completi, fai ulteriori ricerche e forma la tua opinione):

Una revisione sistematica della letteratura sulla ricerca sui costi della qualità del software (2011)

"Mentre la comunità ha così sviluppato una solida conoscenza della struttura del dominio di ricerca, spesso manca la convalida empirica. Solo circa un terzo degli articoli analizzati presenta un caso di studio o risultati empirici più estesi. Ciò sembra essere insufficiente per la ricerca dei costi di qualità del software , che si basa fortemente su dati quantitativi per generare nuove scoperte. Pertanto, sono necessari nuovi approcci per raccogliere dati sui costi di qualità, nonché una più stretta cooperazione tra industria e ricerca per rendere disponibili tali dati. "

Valutazione del costo della qualità del software (1998)

"Infine, abbiamo visto che è importante monitorare i costi di conformità e non conformità del software in modo che le politiche di conformità possano essere adattate per ridurre i costi totali della qualità del software."

Il comportamento in termini di costi dei difetti del software (2004)

Abstract ... "La ricerca attuale tenta di aggiornare la nostra conoscenza del modo in cui i difetti e le spese per correggerli (o in alternativa, lasciandoli non corretti) influenzano il costo finale del software" ... "i difetti non corretti diventano esponenzialmente più costosi con ogni fase in cui sono irrisolti "

Copertura test e difetti post-verifica: uno studio di caso multiplo (2009)

"Scopriamo anche che lo sforzo di test aumenta in modo esponenziale con la copertura dei test, ma la riduzione dei problemi sul campo aumenta in modo lineare con la copertura dei test. Ciò suggerisce che per la maggior parte dei progetti i livelli ottimali di copertura saranno probabilmente inferiori al 100%."

Colmare il divario tra il processo di test del software e il valore aziendale: un caso di studio (2009)


0

Non posso rispondere alla tua prima parte della domanda, dato che semplicemente non ho verificato. Ma posso formulare una risposta alla tua seconda domanda e forse suggerire una possibile risposta alla prima.

Va da sé che alcuni dei fattori più importanti nel costo della correzione di un bug, escludendo strumenti di sviluppo intrinsecamente difficili da usare, sono la complessità intrinseca del prodotto e la capacità dell'utente di comprenderlo.

Concentrandosi per un secondo sul codice, supponendo che il codice sia tipicamente scritto e gestito da sviluppatori in grado di gestire le complessità intrinseche del loro codice (che potrebbe non essere del tutto vero e meritare il proprio dibattito), oserei suggerire che importanza cruciale nella manutenzione, e quindi nella correzione di bug, è la capacità dei manutentori di comprendere detto codice.

La capacità di comprendere il codice è notevolmente migliorata dall'uso di comprovati strumenti di ingegneria del software che, sfortunatamente, sono per lo più utilizzati in modo insufficiente o improprio. Utilizzare il giusto livello di astrazione, modularità, migliorare la coesione dei moduli e ridurre l'accoppiamento dei moduli sono strumenti fondamentali per far fronte alle complessità che richiedono un uso adeguato. La codifica per interfacce o, in OOP, evitando l'uso eccessivo dell'ereditarietà rispetto alla composizione, il packaging per funzionalità, sono alcune delle tecniche a cui viene spesso prestata scarsa attenzione nella codifica.

Ritengo che le realtà della concorrenza nel settore esercitino una forza negativa sull'impiego di metodi di miglioramento della qualità per lo sviluppo del software, mantenendo bassa la qualità intrinseca del software come misura del successo continuo.

Di conseguenza, ritengo che, nel settore, i software tendano a risentire maggiormente dei costi di correzione dei bug, più cresce. In tali prodotti, i bug diventano più difficili da correggere nel tempo perché il sistema diventa più difficile da capire man mano che cresce. Le preoccupazioni introdotte da ciascuna funzionalità sono eccessivamente accoppiate ad altre preoccupazioni, rendendo difficile la comprensibilità. Oppure, non è stato utilizzato il giusto livello di astrazione, rendendo difficile per il manutentore formulare un modello adeguato del sistema e ragionarlo. La mancanza di documentazione certamente non aiuta.

Ci sono eccezioni Sono sicuro che Google non funziona al suo ritmo senza alcune solide pratiche sostenute da sviluppatori stellari. E altri sono probabilmente nella stessa situazione. Ma per la maggior parte del software, non sarei sorpreso se i dati ha infatti confermano la domanda in codice completo .


Attendo la mia risposta anche con una valutazione negativa. Di recente ho intervistato un candidato che mantiene lo strumento bancario online di una delle migliori banche. Durante una chat informale, ha suggerito di non usarlo, a causa del pesante riutilizzo di copia-incolla e della struttura altrimenti scadente. In un precedente lavoro, ero uno sviluppatore di un'azienda che scriveva strumenti di analisi per banche come Lehman, MS, UBS, e dovevamo agire come esperti di dominio, per capire quale fosse la prossima cosa da mettere sul ramo di altri dalla documentazione più sparsa. Anche se in disaccordo con le pratiche specifiche, il messaggio generale su: industria è vero.
Mihai Danila,

-1

Un'altra risposta! Questa volta per rispondere alla domanda del titolo "La morhtodoligy del software si basa su dati errati"?

La vera risposta è "non ci sono dati". Poiché non esiste un ampio corpus affidabile di dati sui progetti software, vi sono difetti, successi nel time-to-market, ecc.

Tutti i tentativi di raccogliere tali dati sono stati insufficientemente finanziati, statisticamente imperfetti o, così specifici per un determinato progetto, da cui non è possibile trarre conclusioni generali.

Inoltre non credo che ci sarà mai, il processo di sviluppo del software è troppo soggettivo e sfuggente per una misurazione rigorosa. Le organizzazioni nella posizione migliore per raccogliere tali dati (le grandi software house e gli integratori di sistemi) sanno nel loro cuore che qualsiasi cifra raccolta dalle loro prestazioni sarebbe profondamente imbarazzante.

Le uniche organizzazioni che pubblicano numeri sul costo e sul successo dei progetti software
sono dipartimenti governativi, e solo allora perché devono farlo, e sì, questi numeri sono profondamente imbarazzanti, non importa quanto massaggino le cifre.

Quindi, in conclusione, tutti gli studi sul software sono necessariamente puramente soggettivi perché non esistono dati reali su cui basare una conclusione obiettiva.


1
No, non lo compro. Prima di tutto, ci sono dati anche se potresti avere ragione che sono imperfetti. Ma ciò richiede una critica individuale di ogni set di dati, non un licenziamento generale. E sono profondamente sospettoso della tesi secondo cui non ci saranno mai dati, e per ragioni come "è troppo soggettiva". Questo è essenzialmente un argomento per mancanza di immaginazione . Non pretendo che la raccolta di statistiche affidabili qui sia facile, ma sostengo che sia del tutto fattibile. In altri campi, i sistemi più complicati vengono analizzati con successo.
Konrad Rudolph,

@Konrad: prendi qualcosa di semplice e semplice come il "conteggio dei difetti", alcuni negozi contano i fallimenti dei test unitari, alcuni negozi non iniziano a tracciare i difetti fino a UAT, alcuni negozi tracciano solo i difetti nel codice, alcuni negozi includono documentazione, configurazione e script di distribuzione nel processo di rilevamento dei difetti. Avere il colore di sfondo sbagliato conta come un difetto? Alcuni progetti lo seguiranno come un difetto, altri lo ignoreranno.
James Anderson,

Questi sono tutti problemi parrocchiali - cioè risolvibili -. Non pongono vincoli fondamentali su ciò che è possibile, aggiungono solo difficoltà che richiedono una soluzione.
Konrad Rudolph,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.