Esiste una correlazione tra alcune pratiche di ingegneria del software e le storie di successo dell'ingegneria del software?

8

Ho letto il libro " The Drunkard's Walk: How Randomness Rules Our Lives " di Leonard Mlodinow ed è una lettura veramente illuminante. Il libro tratta delle probabilità e del ragionamento umano. E diciamo, per la cronaca, che mentre alcune cose a volte funzionano, c'è una possibilità che le cose che pensavi abbiano funzionato, non sono correlate a ciò che ha effettivamente fatto funzionare.

Probabilities are unintuitive.

Tuttavia, mi ha dato un'idea. Dovrebbero esserci già studi su questo, che hanno tentato di quantificare i risultati degli sforzi di ingegneria del software (che ovviamente è un problema difficile in sé). E questi studi dovrebbero indicare quale tipo di pratiche di ingegneria del software sono davvero importanti in termini di successo quantificabile.

vale a dire.

  • Un team che impiega TDD è this molto meno probabile che abbia il tipo di problema this .
  • Un team che impiega i principi SOLID è this molto meno probabile che abbia this tipo di problema.
  • ecc. ecc.

Quello che sto cercando qui sono le pratiche di ingegneria del software che mostrano una strong correlazione tra implementazione e successo. Sono fiducioso che queste cose esistono ma che sono difficili da trovare ed è per questo che pongo questa domanda.

Quali studi o quali pratiche conosci che hanno una strong correlazione tra implementazione e successo (dove il successo è alquanto arbitrario ma penso che tu abbia ottenuto l'idea)?

If we're gonna sell that idea that software engineering is better than cowboy coding, I think we need proofs.

    
posta John Leidegren 07.02.2012 - 08:38
fonte

1 risposta

10

Il problema con questo tipo di quantificazione è che è quasi impossibile ottenere dati sufficienti sull'efficacia delle pratiche di ingegneria del software per trarre conclusioni significative.

Soprattutto, correlazione non implica causalità - ad esempio, potrebbe essere solo che i bravi programmatori sono pronti a saltare e implementare nuove idee, quindi vedi una correlazione generale tra successo e adozione del progetto di nuove tecniche di ingegneria del software. Ma questo non prova nulla dell'efficacia delle tecniche stesse, poiché l'intero effetto potrebbe essere spiegato dal livello di talento più alto dei programmatori che li adottano.

E quindi è difficile controllare le variabili indipendenti . Come garantisci un equo divertimento a meno che tu non sia in grado di controllare tutti i seguenti?

  • Livello di esperienza / abilità / motivazione del team
  • Estensione effettiva dell'adozione della metodologia dichiarata (stanno davvero facendo correttamente TDD?)
  • Presenza / assenza di errori di progettazione principali non correlati alla metodologia di ingegneria del software (ad esempio quelli che richiedono una grande re-architettura durante il progetto)
  • Livello di difficoltà dei progetti confrontati
  • Impatto di problemi imposti dall'esterno (ad esempio modifiche ai requisiti principali)
  • Bias di selezione (ad esempio, le persone tendono a condividere i dati più spesso su progetti di successo?)
  • Pregiudicazione della conferma (ad esempio, le persone hanno esagerato il successo dei progetti che utilizzano la loro metodologia preferita?)

Anche se decidi di affrontare quanto sopra, assegnando a più team accuratamente selezionati lo stesso problema nelle stesse condizioni attentamente controllate, il tuo esperimento sarà probabilmente eccessivamente costoso se vuoi creare abbastanza dati per essere statisticamente significativo.

E infine quasi impossibile misurare il successo :

  • Una metrica relativa alle quantità come linee di codice sorgente (SLOC) è terribilmente pessima. L'incentivo per gli sviluppatori è creare mostruosità di milioni di righe con codifica copia / incolla per apparire più "produttivi"
  • Una metrica sul tempo / sul budget dipende principalmente dal livello di ambizione nelle stime utilizzate per creare il piano / budget
  • Una metrica di tipo ROI dipende tanto dalla situazione del mercato e dalla gestione commerciale del prodotto quanto dalla qualità dell'output ingegneristico (guarda la cronologia di Microsoft Windows!)
  • I punti storia sono utili per avere una sensazione di velocità in una squadra agile ma non sono paragonabili tra i vari team
  • Le metriche basate sulla funzionalità come punti funzione o Use Case Points sono forse i migliori di un brutto gruppo, ma sono burocratici raccogliere e non riflettere la differenza nello sforzo ingegneristico necessario per creare ogni unità di funzionalità.
  • Le metriche di qualità come i bachi nella disponibilità di produzione / app sono notoriamente difficili da calcolare e confrontare su base di parità - dipende in modo significativo da cose come la piattaforma scelta, la dimensione della base di utenti e vari fattori operativi / di implementazione.

In conclusione: cercare di quantificare l'impatto delle attività di sviluppo del software è un compito estremamente difficile, e nonostante molti anni dopo l'argomento nessuno ha ancora trovato un approccio veramente efficace. Di conseguenza, la valutazione delle metodologie di sviluppo del software rimane più un'arte che una scienza e probabilmente lo rimarrà per molti anni a venire.

È interessante notare che esiste un approccio che ritengo possa promettere: applicazione dei principi snelli . Questa non è una panacea e non risolverà direttamente il problema della valutazione delle metodologie di sviluppo del software, ma ha una visione chiave: Un processo con un particolare elemento di rifiuto è inequivocabilmente meno efficiente dello stesso processo senza quell'elemento di rifiuti, a parità di altre condizioni . Quindi, se ti concentri sull'eliminazione degli sprechi nel processo di sviluppo del software, puoi almeno essere sicuro che ti stai muovendo nella giusta direzione. Inoltre, i rifiuti sono spesso quantificabili, quindi dovresti anche avere un'idea di quanto tu stia ottenendo, almeno in termini approssimativi.

    
risposta data 07.02.2012 - 09:11
fonte

Leggi altre domande sui tag