Perché il settore IT non può realizzare rapidamente progetti di grandi dimensioni e senza difetti come in altri settori?


509

Dopo aver visto la serie MegaStructures di National Geographic , sono rimasto sorpreso dalla rapidità con cui sono stati completati i grandi progetti. Una volta svolto il lavoro preliminare (design, specifiche, ecc.) Su carta, la realizzazione stessa di grandi progetti richiede solo pochi anni o talvolta alcuni mesi .

Ad esempio, Airbus A380 "lanciato ufficialmente il 19 dicembre 2000" e "all'inizio di marzo 2005" , l'aereo era già stato testato. Lo stesso vale per enormi petroliere, grattacieli, ecc.

Confrontando questo con i ritardi nell'industria del software, non posso fare a meno di chiedermi perché la maggior parte dei progetti IT sia così lenta, o più precisamente, perché non possano essere così veloci e impeccabili, alla stessa scala, dati abbastanza persone?


Progetti come Airbus A380 presentano entrambi:

  • Principali rischi imprevisti: sebbene questo non sia il primo aereo costruito, spinge ancora i limiti della tecnologia e le cose che hanno funzionato bene per gli aerei di linea più piccoli potrebbero non funzionare per quello più grande a causa di vincoli fisici; allo stesso modo, vengono utilizzate nuove tecnologie che non erano ancora state utilizzate, perché ad esempio non erano disponibili nel 1969 quando Boeing 747 fu realizzato.

  • Rischi connessi alle risorse umane e alla gestione in generale: persone che abbandonano nel mezzo del progetto, incapacità di raggiungere una persona perché è in vacanza, errori umani ordinari, ecc.

Con questi rischi, le persone realizzano ancora progetti come quei grandi aerei di linea in un periodo di tempo molto breve e, nonostante i ritardi di consegna, quei progetti hanno ancora un enorme successo e di alta qualità.

Quando si tratta di sviluppo software, i progetti non sono così grandi e complicati come un aereo di linea (sia tecnicamente che in termini di gestione) e presentano rischi leggermente meno imprevisti dal mondo reale.

Tuttavia, la maggior parte dei progetti IT sono lenti e in ritardo e l'aggiunta di più sviluppatori al progetto non è una soluzione (passare da un team di dieci sviluppatori a duemila a volte permetterà di consegnare il progetto più velocemente, a volte no, e a volte danneggerà solo il progettare e aumentare il rischio di non finirlo affatto).

Quelli che vengono ancora consegnati possono spesso contenere molti bug, che richiedono service pack consecutivi e aggiornamenti regolari (immagina "l'installazione di aggiornamenti" su ogni Airbus A380 due volte alla settimana per correggere i bug nel prodotto originale e prevenire il crash dell'aeromobile).

Come si possono spiegare tali differenze? È dovuto esclusivamente al fatto che l'industria dello sviluppo software è troppo giovane per essere in grado di gestire migliaia di persone in un singolo progetto al fine di fornire prodotti su larga scala, quasi senza errori molto velocemente?


127
Domanda interessante. Sono tentato di dire che la qualità del lavoratore medio nell'industria del software è meno qualificata e qualificata rispetto, per esempio, all'ingegneria civile in cui ogni ingegnere ha conseguito una laurea rigorosa e intensiva e probabilmente ha anche acquisito il suo statuto. Inoltre, lo spazio di complessità di software di grandi dimensioni (ad esempio un sistema operativo, MS Office) è probabilmente molto più grande anche di un aereo. Certamente molti altri posti dove fallire! E un ultimo punto importante: la maggior parte dei software funziona più o meno, anche se è stata scritta male e presenta un errore elevato ... sicuramente il costo del guasto è normalmente molto inferiore a quello di un aereo!
Noldorin,

155
Trova qualcuno che effettivamente lavora in uno di quegli altri settori (ma non in PR) e chiedi loro di "grandi progetti senza errori". Posso praticamente garantire che ti farai ridere il dolore.
Michael Borgwardt,

151
La realizzazione di un progetto software richiede secondi o minuti; è ciò che accade quando fai clic su "compila" nel tuo IDE. D'altra parte, la programmazione è design . Quanto tempo ci è voluto per progettare l'A380?
Formica,

53
Quel programma TV è un clamore. Trasmettono solo progetti di successo. Qualsiasi canale farà programmi per l'attenzione degli spettatori.
Pandu,

117
'immagina "l'installazione di aggiornamenti" su ogni Airbus A380 due volte alla settimana ...' Immagina che i robot nemici sondino costantemente l'aereo per le vulnerabilità mentre i piloti non addestrati spingono i pulsanti a caso. Scommetto che avresti bisogno di patch regolari.
Nathan Long,

Risposte:


337

La Marcia della morte di Ed Yourdon tocca alcune di queste domande sul meta-tipo.

In generale, all'industria del software mancano molte delle cose seguenti, che ostacolano i grandi progetti.

  • Standardizzazione e scomposizione degli elementi di lavoro.

    • Questo è sicuramente migliorato, ma i costrutti di design non sono ancora lì per rompere un grande sistema. In un certo senso, il software non può nemmeno essere d'accordo su ciò che è necessario per un determinato progetto, tanto meno essere in grado di scomporre le cose in componenti.
    • Aerospace, edilizia, auto, ecc. Tutti hanno architetture guidate da componenti con interfacce ragionevolmente strette per consentire uno sviluppo completamente parallelo. Il software consente ancora un eccessivo spurgo nelle aree corrispondenti.
  • Un gran numero di progetti simili e di successo. L'A380 non è stato il primo grande aereo che Airbus ha costruito. Ci sono molte grandi applicazioni software là fuori, ma molte di esse hanno sofferto in modo drammatico in un aspetto o nell'altro e non si avvicinano ad essere chiamate "di successo".

  • Un gran numero di designer e costruttori che hanno lavorato a numerosi progetti simili e di successo. Relativo al successo del progetto, non avendo il talento umano che è stato lì, fatto che rende le cose molto difficili da un punto di vista della ripetibilità.

  • "Mai" costruire la stessa cosa due volte. In molti modi, un aeroplano è come qualsiasi altro aeroplano. Ha ali, motori, sedili, ecc. I grandi progetti software raramente si ripetono. Ogni kernel del sistema operativo è significativamente diverso. Guarda la disparità nei file system. E del resto, quanti SO davvero unici ci sono? I più grandi diventano cloni di un elemento base ad un certo punto. AIX , Solaris , HP-UX , ... herald torna a AT & T System V . Windows ha avuto un'incredibile quantità di trascinamento in avanti attraverso ogni iterazione. Le varianti di Linux in genere risalgono tutte allo stesso core avviato da Linus. Lo sostengo, perché le varianti tendono a propagarsi più velocemente dei sistemi operativi proprietari davvero unici.

  • Stima del progetto davvero pessima. Poiché il fattore di ripetibilità è così basso, è difficile prevedere quanto sarà grande e quanto tempo impiegherà a costruire. Dato che i project manager e la direzione non possono mettere le mani sul codice e vedere effettivamente cosa si sta facendo, vengono generate aspettative non realistiche riguardo alle tempistiche.

  • Il QA / QC non è enfatizzato nel modo più intenso che potrebbe o dovrebbe essere per progetti più grandi. Ciò risale al fatto di avere interfacce più libere tra i componenti e di non avere specifiche rigide su come dovrebbero funzionare i componenti. Questa scioltezza consente conseguenze non intenzionali e l'insorgenza di bug.

  • Qualifiche coerenti e misurabili. Generalmente, le persone parlano del numero di anni in cui hanno lavorato nel linguaggio X o nella programmazione. Time in viene utilizzato come sostituto del calibro o della qualità delle abilità. Come è stato menzionato molte volte, è difficile intervistare e trovare bravi talenti della programmazione. Parte del problema è che la definizione di "buono" rimane molto soggettiva.

Non intendo essere tutto negativo, e penso che l'industria del software abbia fatto passi da gigante da dove siamo stati. Forum come questo e altri hanno davvero contribuito a promuovere la conversazione e la discussione dei principi di progettazione. Ci sono organizzazioni che lavorano per standardizzare le conoscenze "di base" per gli ingegneri del software. Vi sono certamente margini di miglioramento, ma penso che l'industria abbia fatto molta strada in un periodo di tempo ragionevolmente breve.


23
È stato difficile scegliere una risposta da accettare tra molte risposte molto valide, ma alla fine seleziono questa nonostante il fatto che non abbia il punteggio più alto. In effetti, sia questa risposta che quella di m3th0dman spiegano esattamente perché esiste una tale specificità nel settore IT, aiutando a capire cosa fare in futuro per colmare il divario. Rispetto alla risposta di m3th0dman, questo sembra molto più dettagliato.
Arseni Mourzenko,

3
+1, ma potrei solo aggiungere che, poiché il software esiste nel regno della mente, ha possibilità quasi infinite , mentre ogni piano che ogni costruzione deve affrontare con i requisiti finiti della realtà.
Spencer Rathbun,

5
Molto ben risposto. Come esempio interessante - immagina se un grande aereo è stato progettato e implementato da un gruppo di persone senza processo o storia aziendale - persone che si sono appena riunite e hanno formato un business per costruire un aereo sulla scala di un 747 da zero. Ecco come sono stati realizzati il ​​90% dei progetti software che ho visto. L'altro 10% con architetti e aziende esperti con storia e processo sembra avere molto più successo. Per un contro-esempio, guarda il processo di sviluppo dietro il software che causa la morte delle persone quando fallisce.
Bill K,

7
Penso che tu abbia accettato la risposta sbagliata. Danny Woods aveva ragione, i fallimenti in altri settori sono altrettanto frequenti e la programmazione non sta costruendo il suo design. La costruzione nel mondo del software è fatta dal compilatore ed è praticamente gratuita. La tua domanda originale era molto significativa Una volta che il lavoro preliminare (progettazione, specifiche, ecc.) È stato fatto su carta, il lavoro di progettazione e specifica di una struttura fisica è una specifica ESATTA di come costruire la struttura. L'unica cosa che corrisponde al mondo del software è il codice. Il codice è design, la compilazione è costruzione.
Michael Brown,

5
Ma la domanda in sé è imperfetta. Mentre abbiamo bisogno di rivolgere un occhio critico verso i nostri difetti. Agire come se l'industria del software fosse l'unica ad avere progetti infruttuosi è ridicola. Dire "una volta che tutto il design è stato fatto" è altrettanto significativo. Anche se non sei d'accordo sul fatto che la programmazione sia un'attività di progettazione, con quale frequenza vedi un design dettagliato e ironico fatto in anticipo per il software? Le persone forniscono specifiche sfocate sul software perché prevedono di poter cambiare il software se le specifiche non fossero corrette senza preoccuparsi di come tali modifiche potrebbero influire sull'intera soluzione.
Michael Brown,

452

La risposta è sorprendentemente semplice: quei 'altre industrie' non hanno un alto tasso di fallimento. Stiamo solo confrontando le cose sbagliate. Il software di scrittura viene spesso chiamato "build", quindi lo confrontiamo con le fasi di produzione o costruzione in altri settori. Ma se lo guardi, non è affatto costruzione: è design . I progetti di software sono scritti in codice e la costruzione è fatta dai computer, sia compilando il software che interpretandolo direttamente al volo.

Molti progetti in altri settori impiegano molto più tempo del previsto, costano molto di più o semplicemente non vedono mai il completamento. Suona familiare?

Quindi, cosa stiamo facendo quando stiamo pianificando un software? Bene, stiamo ancora progettando, ma in una fase precedente.

Nel software non esiste una linea di produzione nota. Costruire il componente finale è (relativamente) economico, e la replica di quel prodotto finale è sia perfetta che efficacemente gratuita: copi i manufatti di costruzione.


47
Anche nel settore menzionato dall'OP, Aerospace, Boeing 787 Dreamliner e JSF F-35 hanno entrambi avuto ritardi significativi. La scorsa settimana un parcheggio è crollato in uno dei maggiori centri commerciali di Sydney. Sydney ha standard di costruzione molto rigorosi ma si verificano errori.
teambob,

23
Mille volte questo. Persino il link del programma della domanda mostra che il progetto era effettivamente in fase di sviluppo dal 1988. Il codice sorgente è il design: developerdotstar.com/mag/articles/reeves_design.html
pkh

2
Molti grandi progetti come F-35, Hubble Telescope, ecc. Erano in ritardo a causa del lato software dello sviluppo. La Hubble in realtà rimase in archivio per anni perché il software non era pronto.
MrLane,

11
@MrLane: nel mondo reale funziona così. Viene impostato un programma per quando l'hardware dovrebbe essere eseguito e il software dovrebbe essere eseguito. I progettisti hardware forniscono un ICD al team del software in modo che il team sw possa scrivere il proprio codice senza l'hardware. L'hardware slancia di molto il suo programma e cambia le sue interfacce per aggirare i problemi di hw, spesso senza avvisare il team di sw. Infine, il tipo di hw funziona e viene consegnato, molto tardi. Naturalmente lo sw non funziona a causa della miriade di "caratteristiche" inaspettate di hw. Perché è più economico per risolvere i problemi hardware in ...
Dunk

11
software, il team sw ora deve incorporare le modifiche all'ICD e elaborare soluzioni alternative per l'hardware difettoso. Quindi, oltre alla consegna in ritardo e ora il team di sw sta anche riparando hardware difettoso, chi ha la colpa per essere in ritardo? Bene, il team del software non ha ancora finito. È il software che è in ritardo. Tutti si dimenticano sempre del programma di ingegneria elettrica, meccanica e dei sistemi che dipendono da sw e quindi che costringono il sw a essere riscritto e hanno requisiti extra. Tutto quello che vedono è che la squadra sw sta ancora programmando. Pertanto, il software è in ritardo.
Dunk,

180

Per evidenziare alcune cifre:

  1. Modifica dei requisiti dopo l'avvio dell'attuazione ; per esempio, quando il primo Airbus A380 iniziò a essere creato in fabbrica, non posso credere che se qualcuno volesse altri 200 posti a sedere, quelli sarebbero stati messi lì; ma in un grande progetto software anche dopo che i programmatori hanno iniziato lo sviluppo, è possibile aggiungere altri 5 tipi di utenti.
  2. Complessità : i progetti software di grandi dimensioni sono estremamente complessi; probabilmente i progetti più complessi di tipo umano progettati e sviluppati;
  3. Non sono state spese risorse sufficienti in fase di architettura e progettazione ;
  4. Immaturità sul campo : l'ingegneria del software è una disciplina relativamente giovane rispetto ad altre sorelle dell'ingegneria; ciò ha due implicazioni: a) Non così tante euristiche e buone pratiche; b) Non così tanti specialisti di grande esperienza;
  5. Mancanza di prove matematiche - nella maggior parte dei casi i metodi matematici formali non vengono utilizzati per dimostrare che un software funziona come richiesto; invece viene utilizzato il test. Questo è vero in altri campi dell'ingegneria che si basano maggiormente sulla matematica; la ragione di ciò è come complessità;
  6. Rush : molti manager hanno scadenze irraggiungibili; quindi la qualità del codice è al secondo posto, a causa della scadenza.

Rispondendo rigorosamente alla domanda - Tendo a credere che gli altri abbiano aspettative molto elevate (soprattutto nei tempi di consegna) da parte dei programmatori e non capisco esattamente quanto sia difficile programmare software di grandi dimensioni.


55
La dimostrazione matematica formale nel software, oltre al fatto che spesso è praticamente impossibile fare bene, alla fine non è altro che scrivere due volte il programma (una volta nel linguaggio di programmazione effettivo e una volta nel linguaggio di specifica a prova formale) e verificare che entrambi le versioni fanno esattamente lo stesso.
martedì

5
Inoltre, ci sono strumenti che possono aiutarti a scrivere entrambi contemporaneamente: Coq supporta "l'estrazione di programmi" per estrarre un programma in OCaml o Scheme da un programma Coq certificato.
jkff,

66
"Modifica dei requisiti dopo l'avvio dell'implementazione". Io chiamo questo "spostare il problema della toilette". Stai costruendo una casa, stai dando gli ultimi ritocchi al bagno e il proprietario vuole il bagno in un posto diverso. Dai loro il preventivo. Si sgretolano, dicendo "perché così tanto, voglio solo il bagno a 8 piedi di distanza?". Spieghi quindi che devi installare un nuovo impianto idraulico, strappare pareti / pavimenti aperti, ecc. Per poterti spostare in bagno. Le modifiche in ritardo sono sempre costose.
The Lazy DBA,

7
Direi che testare un aeroplano è in realtà molto più difficile che testare un software. Con l'aereo, tutta la magia matematica che hai evocato finisce inutilmente quando hai pensato che il simulatore software o le turbine eoliche che hai creato non riflettono davvero il modo in cui le cose funzionano quando sei lassù. La prova formale nel software è solo un problema difficile, rispetto alla prova formale in ingegneria che è impossibile.
Lie Ryan,

2
Il numero 1 nella tua lista è l'IMO più importante, aggiungerei altre due cose: -Un sacco di grandi cambiamenti possono essere fatti in un breve lasso di tempo (ad esempio "lascia passare il protocollo di comunicazione!"), Che non romperà le cose a breve termine, ma molti di questi rendono il progetto molto difficile da gestire a lungo termine. - I cambiamenti nell'ambiente in cui viene eseguito il software possono cambiare drasticamente in breve tempo. Mentre i locali di base di un aereo rimarranno gli stessi (devono volare in caso di tempesta, devono atterrare su solide piste, ..), un software può rompersi totalmente, se la nuova versione del sistema operativo viene fuori, ad esempio.
sydd,

140

La premessa della domanda è un po 'imperfetta. Sia l'A380 che il Boeing 787 furono consegnati con anni di ritardo.

Nel caso dell'A380 gran parte del ritardo è stato causato dalle unità francesi e tedesche di Airbus utilizzando versioni diverse e leggermente incompatibili del software di progettazione CATIA . Ciò si è manifestato in modo incompatibile come cablaggi che non si adattavano perfettamente al velivolo.

Non c'era nulla di sbagliato in CATIA, che è il software di progettazione aeronautica più utilizzato, ma qualcuno da qualche parte ha lasciato cadere la palla di configurazione del software.

Il Boeing 787 soffriva anche di ritardi legati al software, ma la maggior parte dei suoi problemi riguardava nuovi problemi aerei più tradizionali come il controllo del peso e la consegna di componenti scadenti da parte dei fornitori.

Sia l'A380 che il B787 hanno dovuto modificare i loro design delle ali dopo che l'aereo iniziale aveva avuto problemi strutturali.

Grandi progetti complessi sono difficili per l'uomo in tutti i campi.


10
Concordato. Penso che ci sia un falso atteggiamento secondo cui il software viene "prodotto in modo più sciatto" rispetto a quello fisico perché il software cattivo finisce con correzioni che sono molto visibili, inoltre tutti hanno a che fare con software non funzionanti. Se un aereo è un pezzo di merda e devono fare un lavoro su di esso, non lo rispedisci indietro, è solo qualcosa di cui i meccanici si lamentano nella maggior parte dei casi, a meno che non sia un enorme difetto. E anche quelli accadono.
Ben Brocka,

6
Penso che la domanda sia ancora valida anche se gli esempi sono errati. È statisticamente provato che i progetti software hanno costi finali molto maggiori e richiedono molto più tempo di quanto previsto.
Euforico,

18
Va notato che la progettazione e l'implementazione di un sistema di aereo di linea commerciale comprende intrinsecamente il completamento di un progetto IT massiccio e enormemente complicato, che deve essere pienamente e correttamente funzionante.
Punta il

6
E dato che l'A380 ha avuto un grande richiamo recente come il 2010, non lo definirei "impeccabile" anche allora.
Muhammad Alkarouri,

3
Inoltre, MOLTI aeroplani concept sono stati finanziati e cancellati nel corso degli anni, in particolare contratti militari. Gli aeroplani non sono affatto buoni esempi, perché non sentiamo parlare di molti dei guasti (classificati) fino a molti anni o decenni dopo.
SilverbackNet,

112

Ragazzo del grattacielo qui. Non sono sicuro di poter rispondere alla tua domanda, ma posso sicuramente far luce su vari elementi del thread. Gli edifici si verificano davvero molto velocemente. Un vincolo importante è la localizzazione (regolamenti). Ma in generale ci vogliono dai 3 ai 10 anni per un edificio alto dall'inizio alla fine.

Penso che confrontare un nuovo edificio con un nuovo progetto software non sia molto preciso. Un nuovo edificio è più vicino a una nuova versione di un kernel o sistema operativo. Sotto questo aspetto lo sviluppo del software è molto più veloce. Non costruiamo mai da zero in quanto questo sarà un compito ad alto rischio per il quale il cliente non si iscriverebbe mai. La maggior parte della progettazione e dello sviluppo negli edifici deriva da progetti comprovati e completati.

Per esperienza personale, solo un progetto su dieci viene mai realizzato. Il processo è guidato dallo sviluppo piuttosto che dal design, quindi nel momento in cui qualcosa come il prezzo dell'acciaio sale, l'intero progetto è fuori dalla finestra o progettato, poiché il design è il componente economico del processo.

Il design impiega un mese per essere concepito schematicamente, da due a sei mesi per progettare lo sviluppo, altri sei mesi per i dettagli e i documenti di costruzione di un team di architetti, consulenti di pianificazione, ingegneri strutturali, ingegneri eolici, ingegneri dei servizi, consulenti di quantità e costi, geometri, ingegneri dell'accessibilità e l'elenco continua ...

L'argomento virtuale contro fisico non è molto preciso. Lavoriamo anche principalmente con strumenti virtuali e inoltre siamo lontani dal tempo e dalla scala del nostro prodotto finale. Nella maggior parte dei casi non possiamo nemmeno testare aspetti di edifici in scala mockup e usiamo la simulazione per provare a prevedere cosa potrebbe accadere.

Per quanto riguarda la complessità ci sono differenze, ma nel complesso è forse la stessa. Non solo abbiamo unità correlate e livelli multipli di astrazioni e interfacce a più livelli, ma anche le persone sono molto specializzate in piccole parti del processo che rendono molto difficile la comunicazione.

Per quanto riguarda l'argomento del design rispetto allo sviluppo, penso che entrambi i processi siano costruiti in base al design. Sembra accademicamente bello tenerli separati, ma non è possibile progettare se non si sa come funzionano le cose. Basta aumentare il rischio di fallimento.

Nel complesso la mia stima (potenzialmente errata) secondo la domanda di OP è che la programmazione è più un'arte che ingegneria. Perché le persone dovrebbero provare piacere e persino farlo gratuitamente, trovare espressione ed eleganza in esso? L'informatica è anche (come sulla carta) più una scienza che ingegneria. Perché dovresti provare a provare algoritmi invece di mettere semplicemente insieme le parti esistenti e lavorare per far funzionare le cose? Non sono sicuro se questo abbia un senso; Non sono un tipo di software.

Un aspetto che mi colpisce con la progettazione e lo sviluppo del software riguarda il mezzo stesso. I computer rendono il lavoro incentrato sull'uomo molto innaturale. Tutto è molto esplicito e ci sono poche tolleranze. È difficile aggirare mentalmente ciò, e alcuni riescono a evitarlo scaricando la complessità all'interno. Se nient'altro questo potrebbe avere qualcosa a che fare con esso?


2
+1 Grazie per la comprensione. "progettare se sai come funzionano le cose" -> "progettare se non sai come funzionano le cose"?
tokland

Ehi costruttore, ho suggerito alcune modifiche a questo post, penso che tu abbia dei punti eccellenti, ho appena provato a ripulire la grammatica.
Steven

Sono assolutamente d'accordo sul fatto che la programmazione sia più un'arte che ingegneria. Trovo spesso la creatività come un aspetto fondamentale nella progettazione del software.
Lanzafame,

1
Non sono d'accordo con l'affermazione che un grande progetto software e una torre abbiano una complessità simile - in base alla mia esperienza di lavoro come ingegnere strutturale e ingegnere del software, direi che la complessità del software è molto più elevata. Probabilmente ci sono molte ragioni per questo, ma quello che suggerirei è che c'è un sacco di spazio di manovra nell'ingegneria; il limite superiore del progetto di costruzione è quasi sempre dato dal costo, e questo è un vincolo morbido. Il software deve essere esatto , poiché i computer non gestiscono bene l'ambiguità. La lastra non funziona? Aggiungi un carico di acciaio, avrà ragione.
Simon Robb,

Alcune persone progettano e costruiscono edifici per piacere. Non ditelo al mio datore di lavoro, ma ora che ci penso alcuni dei miei software sono come la Sagrada Familia: idiosincratica, troppi ornamenti, mai del tutto finiti; ma di design interessante, divertente da costruire e da usare e ancora in piedi.
Peter A. Schneider,

44

Quindi quanto tempo ha richiesto il design di quelli? Anno? Due? Dieci anni? Il design è la parte più complessa della costruzione di qualcosa, la costruzione stessa è facile.

Sulla base di questo articolo , si sta lentamente comprendendo che lo sviluppo del software è principalmente un processo di progettazione in cui il documento di progettazione è il codice sorgente stesso. E il processo di progettazione è completamente diverso dal processo di produzione. Richiede personale esperto ed è impossibile pianificare, poiché anche piccole modifiche ai requisiti possono comportare enormi cambiamenti nell'architettura complessiva del progetto. Questa comprensione è la base per metodologie agili che si concentrano sul miglioramento della qualità del codice come documento di progettazione finale e sull'esecuzione di test e debug come parte del processo di progettazione, proprio come testano i modelli di aeroplani nelle gallerie del vento.

La costruzione stessa è gestita automaticamente dai compilatori. E grazie a ciò, siamo in grado di costruire interi prodotti in pochi minuti.

Il motivo per cui i progetti software sono terminati con enormi ritardi e costi gonfiati è perché i manager pensano ancora di poter stimare, prevedere e pianificare tale processo di progettazione. Questo fallisce più spesso di quanto sia effettivamente valido. Pensano ancora che legando le persone a un rigido processo di costruzione possano in qualche modo aumentare la qualità anche se il risultato finale è per lo più opposto all'aumento dei costi e delle scadenze mancate.


2
"Questa comprensione è la base per metodologie agili". Esattamente. Il metodo a cascata ha senso per i grattacieli: vuoi che ogni dettaglio nel progetto sia giusto prima di gettare le fondamenta. Ma se demolire e ricostruire i grattacieli fosse gratuito e quasi istantaneo, come lo è la compilazione del codice, probabilmente useresti un processo iterativo.
Nathan Long,

22
@NathanLong: Soprattutto se uscivano con nuove forme di calcestruzzo ogni tre anni e qualcuno ha capito come si potevano eseguire più ascensori in un singolo albero, e all'improvviso l'acciaio non era più bello e tutti hanno deciso di costruire le proprie strutture in carbonio fibra. Cose del genere che va avanti per tutto il tempo nel settore del software.
TMN

2
"Lo sviluppo del software è principalmente un processo di progettazione in cui il documento di progettazione è il codice sorgente stesso" mi hai appena aperto gli occhi. Grazie.
Fr. Kevin D.

@TMN Immagina se durante la costruzione di uno skyscrapper, cambiassero la tavolozza dei colori degli interni perché non sembra giusta. Questo vale per qualsiasi componente dell'edificio. Cercare di far funzionare più ascensori su un singolo albero è una cosa, ma dovresti testare 20 elevatori di diversi fornitori prima ancora di provare ad agganciarli tutti all'albero ...
Loïc Faure-Lacroix

@ LoïcFaure-Lacroix: gli ingegneri potrebbero testare 20 diversi ascensori, gli sviluppatori semplicemente utilizzerebbero quello descritto nel post sul blog dove ne hanno sentito parlare per la prima volta. Quindi, quando l'edificio si è aperto e si è verificato un problema con gli ascensori, hanno scoperto che la società che li ha costruiti non esisteva più. Quando provavano a ottenere ricambi da un altro fornitore, scoprivano che i loro ascensori originali usavano un albero non standard ...
TMN,

39

Immagina, nel bel mezzo del progetto dell'Airbus A380, qualcuno ha convocato in una riunione e ha detto: "Heh, potrebbe costruirlo come triplano?" Altri si unirono dicendo: "Sì, sì. Un triplano. Altre ali sono meglio." I prossimi anni vengono trascorsi trasformando il design dell'A380 in una triplano. In un altro incontro, qualcuno dice "Un triplano? È vecchio. Vogliamo un biplano. Basta rimuovere una delle ali."

O immagina, nel mezzo di un progetto di costruzione di un ponte, qualcuno dice: "Heh, abbiamo appena fatto un accordo con una compagnia di navigazione. Hanno bisogno che il ponte sia più alto di 40 piedi, perché le loro navi sono molto più alte. Risolvilo. Grazie. ".

Questi sono solo alcuni dei motivi per cui i progetti software, grandi e piccoli, finiscono per fallire a un ritmo allarmante.


8
Questo è esattamente ciò che accade. I tipi di gestione o i clienti cambiano idea ogni 10 secondi, il che rende frustranti gli sviluppatori. Ho lasciato il mio ultimo lavoro a causa di una schifezza del genere
Erin Drummond,


21

Come persona con un background di ingegneria meccanica che lavora nell'IT, mi sono spesso interrogata sulle ragioni del basso tasso di successo nell'IT.

Come altri in questo thread, ho anche spesso attribuito i fallimenti all'immaturità dell'IT, alla mancanza di standard dettagliati (sì, sono serio, hai mai controllato il foglio standard di un semplice bullone?) E la mancanza di standardizzati componenti e moduli.

Altre industrie, come l'edilizia o la costruzione navale hanno anche molti più "percorsi battuti": conoscenza ed esperienza di un particolare prototipo di soluzione, che - in forma personalizzata - viene riutilizzato più volte. Vi siete mai chiesti perché gli edifici, le navi o gli aeroplani di dimensioni e scopi diversi abbiano un aspetto così simile? (ci sono eccezioni alla regola ovviamente ...)

Questo perché quei prototipi sono ben studiati, ben compresi, generalmente utilizzati e hanno una comprovata esperienza. Non perché non si potesse fare diversamente. Nella standardizzazione IT raramente accade: i progetti (di grandi dimensioni) tendono a reinventare i componenti, facendo ricerca e consegna allo stesso tempo e con le stesse persone!

Ciò porta inevitabilmente a prodotti unici, che sono costosi da sviluppare e riparare, sono soggetti a errori e falliscono in modo imprevedibile in condizioni incerte. E per questo motivo, naturalmente, questi prodotti sono molto più rapidamente obsoleti, scritti e sostituiti a costi altrettanto elevati con solo leggermente migliori. Ciò di cui l'IT ha bisogno è l'equivalente della rivoluzione industriale, che ha trasformato gli artigiani di mezza età in efficienti fabbriche.

Detto questo, ci sono fattori che rendono l'IT davvero unico. A differenza di quegli altri settori citati, l'IT è veramente onnipresente: viene utilizzato in ogni aspetto della nostra vita moderna. Quindi è un piccolo miracolo che l'IT abbia raggiunto questi progressi ed è in grado di fornire i risultati che fa.


5
+1. Un buon esempio per la standardizzazione (foglio standard di un semplice bullone). Nell'IT sono rari i componenti che sono normalizzati. Prendi i moduli di registrazione: ogni sito Web reinventa il proprio, e pochi sono gli sviluppatori che sanno come si comporta il loro modulo di registrazione con unicode, con stringhe vuote, con stringhe troppo lunghe, ecc.
Arseni Mourzenko,

1
@MainMa: scarso esempio, crei i tuoi pulsanti, caselle di testo, caselle di opzione, caselle di opzione da div? No, riutilizzi gli elementi del modulo del browser; e i browser hanno utilizzato gli elementi del modulo del sistema operativo.
Lie Ryan,

4
Stavo piuttosto parlando degli interni, non dei controlli. Prendi un sito web casuale. Puoi usare i caratteri cinesi per la password? Puoi usare password di 25 caratteri? Cosa succederà se si inserisce uno spazio bianco nella password o nel nome utente? Tutto questo potrebbe essere normalizzato, ma non lo è, e ogni persona sta reinventando la ruota per ogni progetto, spesso male, cioè senza hash e / o salatura, o password limitate a sedici caratteri (esempio: MSN), ecc.
Arseni Mourzenko

4
La modifica dell'IT da "artigiani" a "fabbriche" potrebbe non essere possibile. Le fabbriche stanno eseguendo un processo che è già stato creato. I lavoratori di una fabbrica eseguono il loro processo con poco o nessun pensiero umano. Molte fabbriche hanno sostituito gli umani con i robot a causa di questo fatto. Nel software non si sta eseguendo un processo, ma si sta creando uno. La creazione di software sarebbe più simile alla progettazione della fabbrica e dei suoi processi piuttosto che alla sua esecuzione. Sebbene la creazione di software possa beneficiare degli standard, non può fondamentalmente diventare una fabbrica.
mike30,

@ArseniMourzenko è un brutto confronto per confrontare "schede tecniche per bulloni" (ovvero strumenti, attrezzature) con "standard dei moduli di registrazione". I moduli di registrazione sarebbero più simili a "un tetto" o "una porta d'ingresso" (in effetti, ci sono molti milioni di modi per realizzarli). Ciò a cui un bullone si confronta è più simile a un comportamento della pipeline del processore. Non è affatto vicino a ciò di cui abbiamo bisogno: sistema operativo affidabile (con caratteristiche rigorosamente definite, non "i dati possono colpire il disco a seconda delle opzioni di montaggio utilizzate") e strumenti di sviluppo idem (devono essere in grado di controllare il 90% del codice per standard proprietà)
vedi il

15

Temo di non essere d'accordo con la tua affermazione.

Airbus e Boeing sono due esempi di compagnie che costruiscono aerei. Quante aziende che costruiscono aerei ci sono? Pochissimi, se lo paragonassi a quante aziende costruiscono software.

È altrettanto facile avvitare un progetto aereo che avvitare un progetto software. Se solo la barriera d'ingresso fosse così bassa nell'industria aeronautica come nell'industria del software, vedrai sicuramente molti progetti di aeromobili falliti.

Guarda le macchine; Ci sono produttori di alta qualità che costruiscono automobili molto resistenti e altamente avanzate (pensa Land Rover, Mercedes) e ci sono quelli che costruiscono automobili che non dureranno un anno senza doverle riparare (pensa Kia o Cherry). Questo è un esempio perfetto di un settore con una barriera d'ingresso leggermente inferiore, se inizi ad avere giocatori più deboli.

Il software non è diverso. Hai un sacco di prodotti difettosi, d'altra parte, Windows, Office, Linux, Chrome o Ricerca Google sono progetti di altissima qualità che sono stati consegnati in tempo e avevano un livello di qualità simile a quello di un aereo.

L'altro punto che manca a molte persone è la quantità di manutenzione necessaria per la manutenzione di un'auto, una nave cisterna o un aereo che consideriamo un fatto reale. Ogni aereo deve essere sottoposto a un controllo tecnico prima di ogni decollo. Devi controllare la tua auto ogni qualche chilometro e fare cose regolari come cambiare l'olio, cambiare le gomme.

Anche il software ha bisogno di questo. Se solo le persone dedicassero tanto tempo alla diagnostica, alla prevenzione o al controllo dello stato e della qualità del software rispetto ai prodotti meccanici / fisici, mi aspetterei molte meno affermazioni come queste. Leggete i registri dell'applicazione ogni volta prima di avviarlo? Bene .. se fosse un aereo avresti dovuto ;-)


5
Windows spesso non è stato consegnato in tempo (Longhorn, alias Windows Vista, originariamente doveva essere spedito nel 2003). Non conosco Office, ma la maggior parte degli altri progetti software che hai menzionato esplicitamente non hanno scadenze, o il loro programma di rilascio è così frequente che includono qualsiasi funzionalità sia pronta nel rilascio e spinge via tutto il resto fino a quando non è pronto .
Ken Bloom,

2
Questo è un esempio migliore di software di alta qualità: 420.000 linee e bug free: il software che ha alimentato lo Space Shuttle . Intendiamoci, c'erano costi enormi associati all'ottenimento di questo tipo di qualità.
dodgy_coder il

@dodgy_coder, Costruire un aereo sicuro non è neanche economico ;-)
Karim Agha,

1
@PaulNathan decente è molto soggettivo;)
James Khoury il

3
@KarimA .: Costruire un aereo sicuro non è economico, ma gran parte di ciò che rende un aereo sicuro è il software ... Quindi una parte importante della progettazione dell'aeromobile è in realtà la progettazione del software!
timore

10

I blocchi digitali possono essere 1 o 0. Non ci sono intermezzi.

Una progettazione meccanica ha un livello di tolleranza. Posso mettere un rivetto meno che perfetto in un bridge e molto probabilmente non cadrà, tuttavia, nel codice anche solo una volta l'istanza di mettere uno 0 dove dovrebbe essere un 1 può fallire l'intero programma.

A causa della natura logica e interativa dell'informatica, qualsiasi, anche piccolissima modifica, può portare a un drastico fallimento.


21
Una volta ho sentito qualcuno dire "La costruzione sarebbe come programmare se, quando si mette la maniglia finale all'indietro, l'intera casa esplode".
Morgan Herlocker,

9

Mi sono spesso chiesto la stessa cosa. Sicuramente sembra (occasionalmente) che siamo un gruppo di dilettanti che non hanno idea di cosa stiamo facendo. Non mi piacciono le spiegazioni che danno la colpa ai manager o ad altri fattori esterni: noi sviluppatori dovremmo essere responsabili di ciò che creiamo.

Penso che siamo in un business in cui gli errori sono economici . Il software di patching è economico, rispetto alla ricostruzione di un grattacielo o al richiamo di ogni cellulare venduto.

Questo ha creato una cultura in cui gli insetti fanno parte della vita quotidiana . Sono accettati con un'alzata di spalle. Mentre alcuni bug sono probabilmente inevitabili, dovrebbero dominare il nostro lavoro quotidiano ? Capisco perfettamente i manager che non ritengono che il QA valga la pena, proprio perché si aspettano comunque dei bug. Non capisco i programmatori che non fanno ogni sforzo per produrre codice privo di errori, perché correggere i bug è noioso da morire.

In sostanza credo che sia un problema culturale e spero che cambi.


5
Capisci i programmatori che non si sforzano di produrre codice privo di errori, perché ciò richiederebbe il doppio del tempo e la gestione si sta soffocando per implementare queste nuove funzionalità ieri?
Beta

4
Non dovrebbe essere vero anche per altri settori? Non nego che non esistano fattori esterni, ma credo che un cambiamento debba venire dall'interno. Se gli ingegneri del software avessero abbracciato il loro ruolo di esperti nel loro campo, i loro consigli e le loro stime sarebbero stati rispettati e non indovinati dal management. O sono ingenuo?
waxwing

2
Sono spesso sorpreso quando ogni tanto visito un cliente e lo guardo usare il prodotto che sto programmando. Ci sono bug e funzionalità che rendono molto difficile il loro modo di lavorare e, come programmatore, vedo quanto sia facile renderlo molto migliore per l'utente, ma l'utente non se ne è mai lamentato, perché pensa che non valga la pena per denunciarlo.
timore

7

Gli standard e le pratiche di ingegneria sono molto diversi nell'IT (come settore indipendente) rispetto all'aerospaziale . Ciò è forse più facilmente comprensibile considerando come reagiscono i professionisti IT quando incontrano documenti standard per l' IT nel settore aerospaziale . Ad esempio, gli Standard C ++ Joint Strike Fighter che negli ultimi tempi hanno fatto il giro di Internet.

Molti esprimono divertimenti o dimissioni malinconiche (desideriamo poter fare così); e molti rispondono con ridicolo, sostenendo che non esiste un modo pratico per fornire prodotti di consumo in questo modo. Questo può anche essere giusto, date le aspettative, non dei consumatori, ma della gestione. C'è molta sfiducia nei confronti dei programmatori che si limitano a codificare e codificare per alcune settimane, non dimostrando nulla. Dio aiuta il programmatore che si limita a progettare qualcosa per due settimane. Non così con gli aeroplani.

Nel software, le persone si aspettano davvero di avere qualcosa in questo momento. Certo, il ragionamento va, ci vorrà un po 'di tempo per renderlo davvero solido; ma non possiamo avere qualcosa di complesso descritto in termini semplici in una settimana? Si impara anche che le cose complesse descritte in termini onesti e complessi raramente stimolano l'immaginazione; e così molti ingegneri finiscono per essere complici in un mondo immaginario di cose davvero semplici messe insieme in modi creativi (al contrario di un mondo di cose difficili che si fa davvero bene).


5

Alcune cose da me:

1- Standard e parti: sono produttori di aerei , non sviluppatori. Non ne sono del tutto sicuro, ma la mia ipotesi è che molte parti siano esternalizzate. Non costruiscono i propri strumenti / elettronici, ottengono posti da alcune società, i motori sono probabilmente sviluppati altrove, ecc.

I progetti software, d'altra parte, iniziano quasi sempre da zero con solo alcuni piccoli framework / helper in atto.

2- Tempo per colpire il mercato: il tempo non è un problema critico per gli aerei. Scommetto che il design dell'Airbus fu finalizzato anni prima che fosse terminato, e decisero di trascurare qualsiasi grande passo avanti che potesse accadere in quel momento. (Lo stesso vale per le case automobilistiche, ad esempio, la tecnologia all'avanguardia che sviluppano al momento arriverà in strada tra 5-10 anni.)

Per il software devi essere molto agile, se inizio un grande progetto ora e impiego tre anni per svilupparlo senza alcun cambiamento, è molto probabile che io faccia affidamento su una tecnologia che non è più disponibile o che il mio prodotto è completamente obsoleto. Questo a sua volta offre molti problemi.

3- Ciclo di rilascio e versioni. - Un aereo deve essere completamente finito quando viene "rilasciato". Non ci sono versioni beta stabili, build notturne o simili. Inoltre, una volta terminato, può essere modificato solo in piccolo. Non è possibile aggiungere un livello aggiuntivo con 100 posti a un boeing esistente, semplicemente non è possibile.

D'altra parte, il software ha cambiamenti incrementali che spesso sono solo "build che funzionano", ma non necessariamente prodotti finiti. Inoltre, in IT non è insolito dire "ehi, aggiungiamo un altro compartimento bagagli al nostro aereo che contiene ulteriori 50 tonnellate".


5

Penso che la risposta sia abbastanza semplice:

1) La costruzione e l'implementazione fisica sono in circolazione da tanto tempo quanto le persone: abbiamo avuto migliaia di anni per sviluppare i nostri metodi e tecniche per implementare progetti fisici. La "costruzione" del software, che richiede un set di abilità completamente nuovo e diverso, non ha più di 50 anni - non abbiamo ancora avuto abbastanza tempo per capirlo.

2) La costruzione virtuale è più difficile: devi "vedere" nella tua mente cose che non hanno alcuna realtà fisica. Ti richiede di analizzare e sottrarre molte informazioni prima ancora di sapere come dovrebbe essere il tuo prodotto e i passi che ci vorrà per crearlo. Non è così quando si costruisce un ponte o un edificio.

3) Spesso è molto più difficile trovare l'origine di un errore o bug del software rispetto a quando si fa ingegneria fisica. Se una trave si piega, vedi dove si piega e vedi i supporti che lo trattengono e falliscono, ecc. La ricerca di un difetto del software può comportare l'esame di una grande quantità di codice e processi di interazione: difficile, che richiede tempo e non legato al leggi della fisica e della matematica come sono le strutture fisiche.


4

Proverò a rispondere usando una copia integrale di un articolo della musa incorporata di Jack Ganssle. Mentre questo dice firmware ovunque, basta sostituirlo mentalmente con un software.

Rispetto a cosa?

Il firmware è la cosa più costosa nell'universo. Nel suo meraviglioso libro "Augustine's Laws", Norman Augustine, ex CEO di Lockheed Martin, racconta una storia rivelatrice di un problema riscontrato dalla comunità della difesa. Un aereo da caccia ad alte prestazioni è un delicato equilibrio di esigenze contrastanti: autonomia di carburante vs. prestazioni. Velocità vs. peso. Sembra che alla fine degli anni '70 i combattenti fossero più o meno pesanti che mai. Gli appaltatori, perseguendo sempre profitti maggiori, cercarono invano qualcosa che potessero aggiungere che costasse molto, ma che non pesava nulla.

La risposta: firmware. Costo infinito, massa zero. L'avionica ora rappresenta oltre la metà del costo di un combattente. Questo è un pezzo di cambiamento se si considera l'ultimo combattente americano, l'F-22, costa un bel terzo di miliardo di dollari al pop. Agostino ridacchia praticamente di gioia quando racconta questa storia.

Ma perché il software è così costoso? Tom DeMarco una volta ha risposto a questa domanda con queste tre parole: rispetto a cosa? Ha continuato a discutere casi aziendali relativamente noiosi, ma quella risposta mi è risuonata nella mente per anni. Rispetto a cosa? Con il software creiamo abitualmente comportamenti di prodotto di complessità senza precedenti. Certo, il codice è costoso. Ma mai nella storia della civiltà qualcuno ha mai costruito qualcosa di così intricato.

Considera il seguente ordinamento a bolle, rimosso spudoratamente da Wikipedia e non verificato per la precisione:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

Sono solo 110 personaggi non spaziali, forse gettati via in un'ora o due. Supponiamo di non avere software e di dover implementare un ordinamento usando qualche altra strategia. Quanto costerebbe?

Un ingegnere meccanico potrebbe vantarsi che la sua professione ha costruito sorter molto prima dei computer. Considera lo smistatore di carte IBM modello 82 del 1949 ( http://www.columbia.edu/acis/history/sorter.html ) con un throughput di 650 carte al minuto, un numero inferiore rispetto a quello che il nostro frammento di codice potrebbe gestire anche a 4 MHz Z80. Il modello 82, ovviamente, ordinava solo una colonna di una carta alla volta; per ordinare completamente un mazzo potrebbero essere necessarie decine di passaggi.

Quanto tempo ci è voluto per progettare e costruire questa bestia? Anni, senza dubbio. E la sua funzionalità impallidisce rispetto al nostro codice che è molto più veloce e in grado di gestire set di dati giganteschi. Ma era il 1949. Quanto tempo ci vorrebbe per costruire una sorta di bolla a partire da componenti elettronici - senza FPGA e VHDL, o una CPU?

In un'ora ho gestito un diagramma a blocchi approssimativo, uno sopra il livello del chip (i blocchi hanno nomi come "adder", "16 bit latch" e simili). Ma la logica del sequenziamento è chiaramente piuttosto disordinata, quindi ho appena lanciato un PLD, supponendo che ad un certo punto non sarebbe troppo difficile scrivere le equazioni appropriate. E, sì, forse ciò infrange la regola della logica non programmabile, ma progettare ed eseguire il debug di tutta quella logica usando le porte in un ragionevole lasso di tempo è improbabile come un dollaro al litro.

Supponendo parole e indirizzi a 16 bit, il circuito avrà bisogno di circa una dozzina di chiavistelli, additivi e simili a 16 bit. Più memoria. E non ho idea di come i dati non ordinati arrivino nella RAM o come vengano esportati i risultati. Questi sono requisiti di progettazione non specificati. La soluzione esclusivamente software risolve naturalmente questi requisiti semplicemente scrivendo il prototipo della funzione.

La traduzione del diagramma a blocchi approssimativo in uno schema potrebbe richiedere un giorno. Poi c'è il tempo di progettare e produrre un PCB, ordinare e caricare parti (e cambiare il design per affrontare i problemi inaspettati ma inevitabili di fine vita), e quindi ovviamente far funzionare il circuito. Potremmo parlare settimane di sforzi e un sacco di soldi per la scheda, le parti e le attrezzature di prova appropriate.

Tutto questo per sostituire 7 piccole righe di codice. Pochi programmi embedded reali sono meno di 10.000; molti superano il milione. Quanto hardware e quanta ingegneria sarebbe necessaria per sostituire un vero e proprio programma di computer di grandi dimensioni?

Prendi in considerazione un programma reale come un foglio di calcolo. Quanti circuiti ci vorrebbe per realizzarne uno senza un processore? Potrebbe essere la dimensione di una città.

Il firmware è la cosa più costosa nell'universo, ma solo a causa della complessità inimmaginabile dei problemi che risolve. Ma è molto più economico di qualsiasi alternativa. Quindi, quando il tuo capo chiede in modo irritante perché il software impiega così tanto tempo, sai cosa dire. Rispetto a cosa?

Quindi eccolo! Il software / firmware presenta una complessità senza pari.


3

L'ingegneria e la gestione del software sono sostanzialmente diverse rispetto a molte altre aree di ingegneria. I risultati finali non sono fisici e il processo di produzione è il processo di progettazione e sviluppo. La creazione di un'altra copia di un software ha un costo marginale sostanzialmente nullo; tutto il costo si trova nello sviluppo della prima copia.

A causa della giovinezza relativa dell'ingegneria e della gestione del software come disciplina, ci sono alcune informazioni sbagliate e falsità che sono ancora prese in considerazione ( vedi questo riferimento ) che ostacolano lo sviluppo e l'ingegneria del software nel suo insieme.


3
+1 sull'immaturità dello sviluppo del software. L'ingegneria civile ha avuto un paio di migliaia di anni per sviluppare le sue pratiche. L'aerospazio ne ha avuto un centinaio e si basa su altre discipline ingegneristiche. Il software è ancora giovane. Inoltre è normalmente mal compreso. Le persone possono costruire ponti sui flussi o creare aerei di carta da bambini: lo stesso non è vero per il software.
Andy Burns,

3

Non tutti gli sviluppatori sono creati allo stesso modo. Alcuni sono buoni, altri lo sono, beh, no.

Prova a leggere il codice di altre persone continuamente per avere un'idea di ciò che sto dicendo. Troppe dichiarazioni logiche aggiuntive possono aggiungere rischi. Questi rischi possono portare a comportamenti scorretti o bug. Dichiarazioni logiche insufficienti e ora hai riferimenti null. Il buon programmatore lo capisce e sa quando fare cosa e dove. Ma nessuno è perfetto. Le cose sono complesse. Aggiungi il lavoro mal concepito degli altri ed è facile vedere come i progetti scappano.


3

La costruzione delle cattedrali impiegava fino a 100 anni.

Alcuni aerei Airbus necessitano di 1 milione di righe di codice per funzionare.

Più tempo stai migliorando, più miglioramenti ottieni, quindi dai all'industria del software un paio di secoli di errori di prova per migliorare, e vedremo quanto ci vuole per sviluppare un solido progetto senza errori o difetti.


La cattedrale di Colonia fu iniziata nel 1248 e terminata nel 1880. 632 anni.
gnasher729,

3

Grandi progetti si verificano spesso in grandi organizzazioni. Se non hai mai lavorato in un'organizzazione di grandi dimensioni, c'è una cosa che è certa di uccidere prestazioni e produttività: la burocrazia.

Sorprendentemente, molte persone non sanno cosa sia la burocrazia (è spesso confusa con la politica), o anche se / quando hanno un problema di burocrazia.

Di recente abbiamo concluso un progetto per l'implementazione dell'autenticazione con smart card. È stato originariamente stimato in tre mesi. Ci sono voluti 15 mesi. Non ci sono stati costi, budget, ambito o motivi tecnici per il ritardo. Il campo di applicazione era in realtà piuttosto limitato - solo per account con privilegi elevati (account amministratore), circa 1.200 account totali.

Un altro fattore significativo sono i tuoi partner commerciali. Ciò include i fornitori. Se i tuoi partner hanno un problema che introduce un ritardo nel tuo progetto, non ci sono molte opzioni che risolveranno effettivamente il problema del ritardo. Non funzionano direttamente per te e potresti non essere in grado di licenziare quella persona contro un partner che potrebbe essere la causa. Il partner può essere licenziato o essere soggetto a sanzioni pecuniarie o disincentivi, ma ciò non cambia il fatto che il progetto abbia subito un ritardo. Questo è esattamente ciò che è accaduto con Boeing quando hanno intrapreso una gigantesca strategia di approvvigionamento con il Boeing 787 Dreamliner .


3

Ho una versione più breve per te:

Qualunque cosa sia facile da fare o semplificata, scriviamo un programma per farlo al posto nostro.

E poi combatti con il meta-processo.

Di per sé non è molto vero, ma ogni giorno vengono creati migliaia di blog, anziché scrivere motori di blog. Ogni giorno lavorativo vengono scritte migliaia di macro di Excel, anziché scrivere applicazioni di database appositamente progettate per queste.

Ci sono molti altri fattori - alcuni dei quali menzionati qui - ma volevo aggiungere questo punto alla discussione.


Sono d'accordo. I programmi di grandi dimensioni possono essere consegnati in modo impeccabile e nei tempi previsti, perché sono stati eseguiti centinaia di volte in 3 decenni. Ad esempio, un editor di testo.
Droogans,

Non solo, ma il modo in cui forniamo in modo impeccabile programmi di grandi dimensioni che sono stati già eseguiti in precedenza, è semplicemente scaricare il vecchio programma dal suo sito Web e fare una copia. Ma per qualche motivo che non conta come un grande progetto software di successo.
bdsl,

3

Mancanza di responsabilità ... Le persone vengono citate in giudizio quando un aereo si schianta. L'industria del software declina ogni responsabilità in merito a qualsiasi difetto del software, creando quindi una mancanza di incentivi per creare un prodotto robusto e sicuro.


1
Lo dico da molto tempo. Se sei stato citato in giudizio quando l'app si è arrestata in modo anomalo, il codice sarebbe molto più robusto ... E ci sono molte aziende che mi piacerebbe fare causa - prendi ad esempio la MS: quante ore sono perse a causa di tutti i loro aggiornamenti e patch e bug e revisioni che rompono altre cose. Seguili per quelle ore perse e la qualità aumenterà rapidamente.
Vettore

In tal caso, i costi aumenterebbero e le funzionalità diminuirebbero.
Jim G.

1
@JimG. La domanda riguardava l'affidabilità, non la funzionalità né il prezzo. Ovviamente dover rendere un prodotto più affidabile introdurrà più vincoli nel tuo spazio di progettazione e altri aspetti (funzionalità e costi) potrebbero risentirne.
GreyGeek,

4
E il costo di un Boeing 737 è di $ 50-80 milioni. Paghi ogni volta che ne ricevi uno, paghi ogni volta che apri Office? Se venissi pagato ogni volta che qualcuno usava il mio software dannatamente dritto, mi sarei dedicato all'affidabilità.
FlavorScape

1
@Jim G: Preferirei avere 1 versione stabile di un prodotto piuttosto che 5 schifose.
Giorgio,

2

I progetti più grandi hanno un alto grado di separabilità dei sottoprogetti, in cui è possibile definire un numero limitato di vincoli di progettazione; l'intero progetto funzionerà quando questi sottoprogetti saranno completati ciascuno. Se qualcosa va storto in un sottoprogetto, l'intero sforzo non viene messo in discussione; cerchi solo modi alternativi per completare il sottoprogetto (ad esempio usa un motore diverso).

Questo è possibile ma difficile, sia praticamente che come questione di natura umana, in progetti software.

In parte, altre industrie hanno imparato a fondo che questo tipo di separabilità è una buona cosa. Ad esempio, se stai per utilizzare i motori degli aeromobili Rolls Royce, non è necessario utilizzare bulloni e punti di attacco Rolls Royce speciali che funzionano solo con ali con un design particolare, quindi se provi a passare a Pratt e Whitney, devi ridisegnare l'intera ala da zero (che, a sua volta, richiede una riprogettazione completa della fusoliera, che a sua volta richiede di acquistare diversi posti, che a sua volta richiede di acquistare un diverso sistema di intrattenimento in volo, quale...). Potrebbero esserci alcuni collegamenti - non puoi semplicemente scambiare i motori senza preoccuparti - ma i grandi progetti generalmente funzionano meglio quando tali cose sono minimizzate.

Ho postulato che i grandi progetti software progettati come un cluster di piccoli progetti software con interfacce pulite tra loro non falliranno particolarmente spesso, a condizione che il grande progetto sia effettivamente risolto dal cluster di piccoli progetti. (È possibile fare un errore in questo senso.)


2

La creazione di sistemi software è molto diversa dalla costruzione di strutture fisiche. Cioè, l' implementazione è molto diversa. Mentre, ad esempio, costruisci un'enorme nave cisterna, esegui molte attività relativamente semplici (non facili!), Come saldare parti insieme da un robot o a mano, stringere tutti i dadi e bulloni, dipingere, fare la decorazione portando in tutto le attrezzature e i mobili e così via. Tutto questo è roba molto semplice da fare, davvero.

Tuttavia, quando si tratta di software, diventa molto più complesso . Ad esempio, come si implementano esattamente la parte di accesso sicura e le credenziali dell'utente che memorizzano il prodotto? Quali librerie e strumenti puoi usare? Con quali librerie e strumenti conosci? Come si scrive esattamente la funzione hashing + salting e come si garantisce che sia sicura? Puoi farlo in così tanti modi che è impossibile stabilire qualsiasi modello di progettazione pratica reale per questo tipo di cose. Sì, i suddetti modelli di progettazione non esistono su scala minore, come "best practices", ma ogni singolo sistema di software è molto diverso dagli altri, e gli avanzamenti di campo e cambiamenti a ritmo così rapido che è essenzialmente impossibile tenere il passo.

Quando costruisci una casa, non ti imbatti in tali problemi in cui ti rendi conto che i muri di supporto principali sembrano essere inadeguati e devono essere sostituiti, richiedendo di demolire i progressi finora e iniziare dalla base rifacendo i muri di supporto . Affronti tali problemi in fase di progettazione , perché è relativamente semplice prevedere quale tipo di muri di supporto sono necessari al tuo edificio.

Questo non è il caso del software. Non è possibile progettare l'intero prodotto come un'unica entità e quindi implementarlo. Il processo di progettazione del software è generalmente iterativo e gli obiettivi e i requisiti cambiano man mano che il prodotto viene implementato e testato. Lo sviluppo del software nel suo insieme è un processo iterativo in cui le cose di solito cambiano quando meno previsto, e molte volte tali cambiamenti impongono sfide che richiedono più lavoro, più complessità e, sfortunatamente e, in definitiva, più denaro, tempo e duro lavoro per ottenere il risultato giusto.

Quindi, in sostanza, il motivo per cui è difficile realizzare grandi progetti e stimare le tempistiche e le roadmap dei progetti è che lo sviluppo del software e specialmente la progettazione operativa sono campi molto complessi . La complessità è il problema principale.


+1 e per portare avanti l'idea è un fallimento nell'apprezzare quella complessità da parte di persone al di fuori del settore che porta a aspettative non realistiche, politiche irrazionali e design fuori dal comune. Il settore pubblico nel Regno Unito è un esempio perfetto. Per un edificio pubblico, diciamo, la direzione cerca di ottenere il design perfetto con il parere di esperti, un'ampia consultazione e pianificazione del progetto a tenuta stagna prima di tagliare l'erba. Ma metti le stesse persone davanti a un nuovo sistema IT e vedrai le modifiche dell'ultimo minuto ai requisiti, allo schema db, all'interfaccia utente ... "Quanto può essere difficile? È solo un po 'di battitura"
Julia Hayward,

1

La definizione di "grande progetto" è distorta.

Un grande progetto, tecnicamente, può essere consegnato in tempo e in modo impeccabile, a condizione che sia qualcosa che è stato costruito molte, molte volte nel corso degli anni.

  • Un clone di Pac-Man.
  • Una calcolatrice
  • Un editor di testo

Sono sicuro che stai pensando ... "ma quelli sono piccoli progetti! Un editor di testo è semplice ." Non sarei d'accordo con te. I computer sono scandalosamente complicati. Solo l'installazione e la configurazione degli utenti su un sistema operativo a volte può essere difficile e non hai nemmeno scritto il sistema operativo o costruito l'hardware.

I progetti di cui stai parlando sono progetti enormi , simili all'esplorazione dello spazio. Come fai a sapere quanto tempo ci vuole per sviluppare il viaggio inter-galattico? Su quale modello lo basiamo? Hai i noti noti, i noti sconosciuti, i noti sconosciuti e, infine, gli sconosciuti sconosciuti, che si verificano molto nello sviluppo del software.

Penso che il problema sia di aspettativa. Solo perché la tecnologia è lì non significa che usarla avrà successo (o saggio da usare) per un po '. Se altre industrie si comportassero come le industrie del software, avremmo in vendita aspirapolvere alimentati da buchi neri entro la fine del decennio. O alcuni "visionari" avrebbero le risorse per costruire una base lunare e decidere che uno Starbucks "completerebbe" davvero l'esperienza per i visitatori. Non credo che il problema sia l'industria del software, ma le aspettative riposte su di esso.


Aspirapolvere alimentati con buco nero? Che dire della sicurezza funzionale?
Peter Mortensen,

Mancanza di sicurezza funzionale? È una caratteristica! Sosteniamo l'uso di strutture immutabili quando si tenta di pulire qualcosa con l'aspirapolvere buco nero.
Droogans,

1

Sebbene non sia l'unica cosa che si possa menzionare, penso che valga la pena sottolineare una cosa basilare. La maggior parte dei prodotti è concepita per adattarsi al comportamento esistente. Perfino un prodotto che rappresenta una svolta radicale (ad esempio, l'auto) è generalmente costruito per adattarsi al comportamento esistente e semplicemente renderlo un po 'più semplice / facile / economico / qualunque cosa per farlo. Sì, c'è spesso qualche effetto collaterale anche sul comportamento esistente (ad esempio, ottenere carburante per l'auto invece di cibo per i cavalli), ma la maggior parte di questi tende ad essere un effetto collaterale piuttosto lieve.

Al contrario, quasi tutti i software che non cambiano il comportamento degli utenti (ad esempio, lascia che facciano il loro lavoro considerevolmente più facilmente) è sostanzialmente garantito per essere un fallimento completo dal primo giorno. Peggio ancora, i grandi progetti software non solo coinvolgono il comportamento degli utenti a livello individuale, ma il comportamento di grandi gruppi, spesso l'intera organizzazione.

In breve, la progettazione del software stesso è spesso la parte più semplice del lavoro. La parte difficile è ridisegnare il lavoro delle persone per loro. È difficile iniziare con; farlo in un modo che non solo funzionerà, ma sarà anche accettato, è ancora molto più difficile.


1

Airbus A380 non è stato un progetto di successo come hai menzionato. Mi capita di lavorare in una società CAD / CAM, e mi è stato detto che (avevamo anche il prioject Airbus) è stato ritardato di alcuni anni, perché utilizzavano versioni diverse di software in diverse società. Cioè, parti diverse venivano progettate in diverse parti del mondo. E mentre si sono integrati hanno capito che tutto il design non può essere integrato, quindi devono riprogettarlo in una versione. Quindi guardandolo non penso che abbia avuto successo. Se fosse arrivato 2-3 anni prima, sarebbe stato un punto di svolta per Airbus.

Anche per quanto riguarda il software robusto, guardi qualsiasi aereo, automobile (ABS, EPS, controllo del clima, ecc.) O navette spaziali che hanno oltre il 50% di software che li gestisce e mi crede che siano molto robusti. È solo che siamo più vicini al software e ci sono molti più programmi software, quindi vediamo più errori in essi.

Visita: http://www.globalprojectstrategy.com/lessons/case.php?id=23 e scopri quanto Airbus A380 ha avuto successo.


1

Ingegnere del software qui, con un background ingegneristico, e una moglie che lavora nella costruzione. Abbiamo avuto lunghe discussioni (e discussioni) sulle differenze del nostro lavoro.

L'ingegneria del software riguarda la progettazione di cose nuove . Quasi tutto il necessario è stato fatto da qualche parte in una libreria open source. In quasi tutti i lavori in cui un ingegnere del software viene assunto, deve progettare qualcosa che non esiste.

In qualcosa come la costruzione e la maggior parte delle forme di ingegneria, le cose che altrimenti sarebbero in una "biblioteca" nel software sono già completamente progettate. Vuoi costruire una torre? Basta copiare e incollare i piani da una struttura esistente, con alcune modifiche.

In effetti, uno dei motivi principali per cui ho deciso di non diventare un ingegnere è che dedichi la maggior parte del tuo tempo a progettare un miglioramento del 10% su un'invenzione esistente, quando quello stesso tempo potrebbe essere utilizzato per programmare qualcosa di più visibile, come un social network .

Non ci sono molti nuovi progetti in ingegneria; un ingegnere estremamente qualificato è qualcuno che può manipolare un progetto esistente in qualcosa di nuovo o migliorarlo. Ma quasi ogni programmatore dovrebbe modificare i progetti, hackerarli o creare qualcosa di nuovo.

Guarda indietro fino a che punto gli standard sono cambiati completamente, dall'assemblaggio in C ++ a Java, JavaScript, C #, PHP e così via. Non c'è molto codice che può essere riciclato da 10 o 20 anni fa. Questo è molto diverso da dire ... l'industria automobilistica o aeronautica quando è possibile continuare a migliorare i progetti di decenni fa.

La gestione del progetto è notoriamente difficile nel software . Le stime del tempo vengono eseguite meglio dalle persone che svolgono il lavoro , ma quando sono impegnate a fare stime, non scrivono codice . Ciò induce le persone a evitare qualsiasi gestione del progetto.

Spesso, molto codice dipende da persone specifiche e se queste persone sono in ritardo o non sono in grado di esibirsi, il codice non va avanti. Al contrario, se volevi costruire un'auto, puoi semplicemente assumere persone diverse per assemblare le gomme, il telaio, la batteria, il motore e così via. I framework orientati agli oggetti e quelli esistenti lo rendono possibile, ma potrebbe non essere pratico quando si progetta tutto da zero.

Gli errori possono essere consentiti nel software . Il test può essere costoso. Nel software, è molto allettante saltare tutti quei test, quando puoi semplicemente risolvere un crash. Nella maggior parte delle forme di ingegneria, un "incidente" può essere fatale.

Esistono metodi di programmazione che utilizzano test approfonditi, come la programmazione estrema (che è stata effettivamente utilizzata su megaprogetti software). Ma con scadenze strette (che possono essere rese più strette di proposito), è allettante saltare tutta quella programmazione e lanciarla con bug. Lo stile Joel Spolsky di "correggere sempre tutti i bug" farà risparmiare più tempo a lungo termine, ma l'indisciplinato salterà questo e fallirà.

I piccoli progetti sono migliori . Mia moglie una volta mi ha chiesto di trovare un lavoro in una grande azienda. Si è concluso con una discussione secondo cui le grandi aziende sono cattive aziende ... per lei, una grande azienda aveva molte risorse, esperienza, gestione funzionale del progetto e le giuste procedure. Per me, una grande azienda è un dinosauro, dove la maggior parte del tuo tempo viene speso per riparare codice, testarlo e documentazione.

Ho visto progetti IT da un milione di dollari su cui hanno lavorato meno di 10 persone. Un numero maggiore di persone avrebbe rallentato il progetto e aggiunto una burocrazia superflua. WhatsApp è un esempio di un "piccolo" progetto che vale miliardi di dollari. Non è possibile che grandi progetti non siano possibili, ma semplicemente non servono migliaia di persone per produrre miliardi di dollari in software.


0

Uno dei motivi che non è stato realmente trattato nelle altre domande è che il campo del software innova a una velocità che si verifica solo raramente nel mondo dei materiali.

Uno dei motivi è che l'evoluzione del software è un ciclo di feedback positivo perché il software (linguaggi di programmazione, strumenti di creazione, IDE) viene utilizzato per costruire il software. È l'esempio più ovvio per la legge di Ray Kurzweil sull'accelerazione dei rendimenti, che porta a progressi a una velocità esponenzialmente crescente. Dopo aver imparato un framework, un linguaggio di programmazione, un protocollo di comunicazione, è tempo di passare al successivo.

Se gli aeroplani fossero costruiti come software, cambieremmo il materiale con ogni altro modello, raddoppiando la loro capacità e velocità ogni 18 mesi, sostituendo la tecnologia del motore per ogni nuovo modello con qualcosa appena inventato, aggiungendo al contempo la possibilità di nuotare e cercare extraterrestri vita.

Oh, e idealmente ascolta i comandi vocali e si raddoppia come un cinema completamente immersivo, un'arena di paintball e un night club con camera oscura al termine del viaggio di lavoro. La stessa cosa! (La società che ha costruito aeroplani che ti hanno portato in modo affidabile dalla A alla B è andata in aria un anno dopo l'uscita di quella con il cinema, il paintball e il locale notturno.)


Non capisco il tuo punto. Innanzitutto, molte lingue sono piuttosto vecchie. Java ha più di vent'anni. Python ha quasi trent'anni. Sì, ci sono nuove lingue, ma non è che tutti noi abbandoniamo una lingua per passare a una nuova ogni due anni. Mentre l'adozione di un nuovo framework, IDE o linguaggio può essere un fattore di lentezza per un team, non trovo neanche quelli che utilizzano strumenti familiari particolarmente veloci. E l'industria aeronautica? Aerei come il Boeing 787 hanno un sacco di cose nuove che erano difficili da implementare.
Arseni Mourzenko,

@ArseniMourzenko Bene, Java è stato molto popolare per la programmazione dei client Web dopo la sua uscita e per la creazione della GUI quando è uscito lo swing, ma entrambe le mode sono durate solo per alcuni anni. Diamine, non c'era WWW prima degli anni '90. La programmazione web è dove erano gli aerei nel 1910 o giù di lì. Ma questo ritmo è in corso.
Peter A. Schneider,

-1

Per me il problema principale che l'ingegneria del software deve affrontare sono i casi d'uso, utente e multipiattaforma.

Casi d'uso

Quanti casi d'uso ha un aereo? La maggior parte è solo per volare da un posto all'altro. Forse ce ne sono altri come radar, controllo del traffico, ecc., Ma il caso d'uso è chiaro e non molto. Nell'ingegneria del software, siamo di fronte a requisiti poco chiari e utenti che non sanno cosa vogliono. Utenti diversi necessitano di configurazione / flusso diversi, un aereo può essere personalizzato come desidera l'utente (voglio avere tv e frigorifero!)?

Utente

Chi gestisce un aereo? Un pilota, un copilota, alcuni amministratori (se contati) e operatori di torri. Sono tutti professionisti e hanno le loro descrizioni di lavoro chiare. Il software viene utilizzato da nessuno e da manichini, per non parlare di hacker e cracker malvagi, ma deve comunque essere integrabile con altri moduli (come OpenID o Google AdSense ). Se un aereo può essere gestito da manichini mentre sopravvive ancora a missili o ladri ninja, allora puoi dire che l'aereo ha la stessa qualità con il software.

Piattaforme incrociate

Un aeroplano vola solo nel cielo della terra. Non sono sicuro di come gestiscano il clima nebbioso o ventoso o caldo, freddo e umido, ma un aeroplano non è progettato per volare a diversi livelli di gravitazione (rimarrò stupito se riuscirà a volare su Marte ). A volte, un'applicazione deve sopravvivere a piattaforme diverse, come Internet Explorer, Google Chrome , Firefox e Safari per browser (mi dispiace Opera ) o Windows XP / 7/8 o Linux per livello di sistema operativo. Per non parlare dei dispositivi mobili e di diverse risoluzioni e orientamenti.


-1

Se pensi che altre industrie completino progetti senza incidenti, dovresti leggere la storia dell'edificio del Citigroup Center costruito nel 1977. Anche dopo quasi 7 anni di progettazione e costruzione, l'edificio è stato completato con un grave difetto di progettazione che avrebbe causato un crollo da un evento di tempesta previsto ogni 16 anni.

In altre parole, per ogni anno in cui il Citicorp Center era in piedi, c'erano circa 1 su 16 possibilità che sarebbe crollato.

I progettisti originali non erano a conoscenza dei problemi, ma per fortuna è stato catturato da uno studente che studiava l'edificio.

tutto sembrava perfetto, finché, come dice LeMessurier, ricevette una telefonata. Secondo LeMessurier, nel 1978 uno studente universitario di architettura lo ha contattato con un'audace pretesa sull'edificio di LeMessurier: che il Citicorp Center poteva esplodere nel vento.

Le riparazioni sono state fatte letteralmente nella copertina della notte coinvolgendo il minor numero di persone per mantenere il segreto del difetto di progettazione.

È stato preparato un piano di evacuazione di emergenza per il raggio di 10 blocchi che circonda l'edificio.

Saldarono per tutta la notte e si fermarono all'alba, proprio mentre gli occupanti dell'edificio tornavano al lavoro.

La storia è rimasta segreta fino a quando lo scrittore Joe Morgenstern ha sentito che veniva raccontato a una festa e ha intervistato LeMessurier. Morgenstern ha rotto la storia in The New Yorker nel 1995.

Il che solleva la domanda; quanti altri fatali difetti di progettazione nei progetti sono stati segretamente riparati o ignorati senza riconoscimento pubblico.

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.