Quali metodi gli ingegneri del software devono limitare i tempi di sviluppo? [chiuso]

tl; dr summary : l'ingegneria del software è una disciplina giovane che sta ancora cercando di costruire progetti complessi e 8 MLOC è un progetto ampio e complesso molto .

L'ingegneria del software è giovane. Molto giovane. Come, due ordini di grandezza più giovani di altre discipline ingegneristiche. L'ingegneria del software è iniziata con la prima conferenza di ingegneria del software NATO nel 1968, mentre ad es. L'ingegneria civile, l'ingegneria strutturale e l'ingegneria meccanica sono iniziate più o meno con la costruzione della Grande Piramide ... cioè 60 anni contro 4600 anni di esperienza.

O, per dirla in parole povere: non l'abbiamo ancora capito.

Ci sono un paio di cose che rendono l'ingegneria del software diversa dalle altre discipline ingegneristiche, soprattutto il fatto che il software può essere copiato e riutilizzato a costo zero e che il software può essere astratto, parametrizzato e generalizzato. Ciò significa che di solito costruiamo solo cose che nessuno ha mai costruito prima, perché se qualcuno l'aveva prima di crearlo, potremmo duplicare questa soluzione senza alcun costo. Questo è diverso da ad es. Ingegneria strutturale. Non puoi semplicemente schioccare le dita e clonare un bridge, ma puoi farlo con il software.

Quindi, altre discipline ingegneristiche hanno decenni, secoli, persino millenni di esperienza che perfezionano l'edificio (più o meno) la stessa cosa più e più volte, mentre SE ha solo 6 decenni di esperienza nella creazione di cose completamente nuove ogni volta.

Oh, e non fare errori: se pensi che confrontare il sistema software dell'F-35 con una delle grandi meraviglie del mondo antico sia ingiusto con gli erculean sforzi degli antichi egizi, direi che la complessità della costruzione di un sistema software sofisticato e avanzato come gli F-35 con la sua avionica, fusione dei sensori e ambiente di realtà virtuale (solo per citarne alcuni) è paragonabile alla complessità di costruire qualcosa come la Grande Piramide.

L'F-35 non è in realtà un piano ma tre. L'F-35C ha ali più grandi, quindi la sua aerodinamica è diversa. L'F-35B è in realtà un aeromobile completamente diverso in uno, uno che genera l'ascensore con le sue ali e uno che genera il sollevamento con il suo ventilatore e l'ugello del motore. Mentre questo progetto risparmia costi e riduce la complessità (almeno questa è l'idea, ci sono persone che affermano diversamente) rispetto allo sviluppo e al mantenimento di tre diversi aerei, ovviamente aggiunge complessità rispetto ad ogni singolo aereo che sarebbe ipoteticamente stato sviluppato, se non lo avessero scelto il concetto "Joint".

Aggiungete a ciò il fatto che questo è un progetto governativo, in cui vi sono molti interessi potenzialmente in conflitto che influenzano il progetto che in realtà non hanno nulla a che fare con i requisiti intrinseci funzionali o addirittura non funzionali del progetto.

8 MLOC è un grande progetto. Pensa al kernel di Linux, la sua dimensione totale è pressappoco la stessa (~ 10 + MLOC al momento, penso). Ma circa il 90% di quel codebase sono driver di dispositivo (ad esempio per dozzine di schede grafiche, dozzine di controller SCSI, oscuri dispositivi di input e output industriali di cui non si è mai sentito parlare, ...), quindi actual Il kernel di Linux è solo di circa 1 MLOC. Di che , il 90% è codice di supporto specifico dell'architettura (per circa 20 architetture di sistema da non meno di 3 architetture PC (x86 (32 bit), amd64 (64 bit) e x32 (amd64 in lungo modalità, ma con puntatori a 32 bit per risparmiare spazio)) a più architetture ARM, PowerPC, MIPS diverse per CPU che non hai mai nemmeno sentito nominare). Quindi, il sistema operativo reale è solo di circa 100 KLOC. Ora, un sistema operativo è generalmente considerato un sistema complesso e Linux è considerato un sistema operativo di grandi dimensioni. Bene, il sistema software dell'F-35 è circa 100 volte più grande!

What methods are there to limit development time in large software projects?

Questo è essenzialmente ciò che è l'ingegneria del software.

Una cosa da considerare su questo particolare esempio è che non è semplicemente la dimensione della base di codice o la complessità di quel codice. Un grande fattore qui è il rischio coinvolto. Considerare un raggio di 20 metri sulla larghezza di un raggio di equilibrio impostato a meno di un metro dal suolo. La maggior parte delle persone che possono camminare prenderebbe in considerazione l'idea di attraversare quel raggio per essere abbastanza facile. Consideriamo ora quello stesso raggio esatto posto a 20 metri dal suolo (in un ambiente controllato, cioè senza vento.) Ora la maggior parte delle persone considererebbe questo compito molto più difficile e farebbe più attenzione a camminarci sopra.

L'atto di attraversare il raggio non è diverso in entrambi i casi, ma chiaramente non è lo stesso chiedere a qualcuno di fare uno sopra l'altro. La differenza sono le conseguenze dell'errore. Il caso che hai scelto qui è quello in cui i rischi sono immensi. 1. A quanto ho capito, un jet da combattimento è instabile e i sistemi informatici sono tenuti a tenerlo in volo. 2. Il radar, la navigazione, l'invisibilità e i sistemi di puntamento sono fondamentali per renderlo adeguato alla battaglia, ad es. potrebbe essere distrutto facilmente dai nemici se i sistemi del computer non funzionano perfettamente.

La maggior parte dei software non ha questo livello di costo. Di solito stiamo camminando attraverso il raggio che è basso verso terra. Se cadiamo, è una conseguenza limitata. Questo progetto è uno di quelli in cui le persone potrebbero morire e le guerre potrebbero essere perse se fossero state ingannate. Il livello di rigore e revisione è praticamente massimo.

Nel complesso, ritengo che la risposta breve sia che il software oggi si sviluppa molto più rapidamente di quanto fosse in passato. Non ho dati, ma sono stato in giro abbastanza a lungo da notare i cambiamenti. Ci sono varie ragioni per questo incluso ma non limitato a: migliori linguaggi di programmazione, migliori processi di sviluppo, migliori standard e una migliore gestione dei progetti. Uno dei principali fattori è stato l'abbandono da parte del settore di modelli di gestione che non erano appropriati per lo sviluppo del software.

Le dimensioni del software dell'F-35 non sono così grandi quando rispetto ad altri sistemi .

Il processo di sviluppo può fare una differenza enorme .

Semplice passaggio da cascata e feature + rami di integrazione a sviluppo basato su trunk (con un sacco di automazione dei test e un buon sistema CI che lo supporta) può ridurre significativamente i tempi di sviluppo per progetti di sviluppo software molto grandi / complessi.

Tale transizione in un software per apparecchiature di telecomunicazione (molte volte superiore a quello degli F-35) ha ridotto i tempi di sviluppo quasi della metà. Ridotto anche il numero totale di checkin a circa il 30% - risparmiando molte risorse precedentemente sprecate all'inferno dell'integrazione e cercando di stabilizzare quei rami che non erano realmente ciò che è stato spedito alla fine.