it-swarm.it

Perché il software non è affidabile come un'auto?

Ho avuto un utente mi ha fatto questa domanda. Sappiamo che le auto si rompono, ma questo è a causa di qualcosa di fisico (a meno che non sia coinvolto un software!).

Ho cercato di rispondere che il software è un settore molto più giovane, ma l'utente ha risposto "L'industria automobilistica non è diventata molto più stabile e affidabile con meno persone?".

Ho anche provato a rispondere che il software è più complesso, ma l'utente ha risposto che ci sono molte migliaia di parti che compongono un'auto. Le persone che progettano e costruiscono automobili generalmente conoscono molto bene i loro componenti, ma finiscono comunque per lavorare insieme come risultato finale.

Quindi, perché il software non è affidabile come un'auto?

65
Alex Angas

La premessa della tua domanda è semplicemente errata: il software non è "meno affidabile" di un'auto. Esistono miliardi su miliardi di dispositivi là fuori che eseguono software incorporato 24x7, per anni e anni, senza problemi. Cavolo, alcuni di essi sono in auto e controllano/monitorano il motore. Quindi, come può il software essere meno affidabile di un'auto, se le auto stesse si affidano al software?

183
GrandmasterB

Progetto software e parti meccaniche.

È complessità.

Perché ci sono milioni di "parti" nel software moderno.

Le parti del software sono molto complicate e hanno molto STATO. Una parte meccanica non mobile non ha stato.

Una parte mobile meccanica ha la sua posizione (una variabile).

Un programma che è in esecuzione e utilizza 1 Mb di RAM ha un milione di byte di stato. Questo è molto più stato di qualsiasi normale sistema meccanico.

Ci saranno combinazioni di stati che non vengono mai testati perché accadono così raramente. In un sistema meccanico (come un'auto) è facile controllare che le parti meccaniche non si tocchino durante il funzionamento. Il meccanico CAD che utilizzo al lavoro lo fa automaticamente.

Se costruissi macchine da parti invisibili e non toccabili, e avessi milioni di parti in movimento che si mancavano tutte, sarebbe come un semplice programma.

Anche "ciao mondo" gira su un sistema operativo. I vecchi sistemi a 8 bit e i sistemi operativi dei minicomputer erano abbastanza affidabili perché erano semplici.

Cose come DLL e librerie condivise vengono sostituite come parte di aggiornamenti di virus o installazioni di software e quindi il programma di interesse non funziona. Un po 'come cambiare la gomma della tua auto per una bicicletta. Alcuni stati Edge della funzione di libreria interferiscono (non agire come previsto dal programma).

I programmi scritti in linguaggi come Java che non consentono molte interazioni non progettate tra oggetti (riutilizzo del puntatore, overflow dei limiti dell'array) sono generalmente abbastanza affidabili una volta che sono stati messi in funzione.
Quando si utilizzano sistemi operativi con librerie statiche, una volta che un programma funziona continua a funzionare (ma avrà comunque molte condizioni Edge, in base alle dimensioni dello stato).

Dave Parnas scrive sull'affidabilità del software riducendo lo stato del programma. I rigidi programmatori funzionali stanno facendo la stessa cosa forzando un singolo compito statico.

115
Tim Williscroft

È una questione di scelta del consumatore.

Se i consumatori chiedessero che il software fosse affidabile quanto la mia Honda Civic (al contrario della mia vecchia Ford Maverick), lo sarebbe. Alcune organizzazioni richiedono software così affidabile e lo ottengono, in genere per software incorporato, a volte per cose critiche per la sicurezza come le missioni spaziali e il controllo del traffico aereo. Il software non è ancora perfetto, ma nemmeno le auto.

Tuttavia, i clienti richiedono altre qualità nei loro software, e per lo più non sono disposti a pagare per software che è forse meno funzionale, sicuramente più costoso, e spedito in seguito solo perché è più affidabile.

56
David Thornley

ci sono molte migliaia di parti che compongono un'auto.

Se solo un computer (e il software associato) fosse così semplice.

Il computer ha un gigabyte di memoria? Miliardi di infradito? Un terabyte di disco? Trilioni di parti "mobili"?

Il software può avere 10 o migliaia o 100 di migliaia di singole righe di codice in esecuzione. Inoltre, molti (o più) test unitari e strumenti.

No. L'argomento "Anche le auto sono complesse" è a castello. Il software è molto, molto, molto più complesso di un'auto.

25
S.Lott

I principi che fanno funzionare i motori a combustione e tutti i componenti che compongono un'auto non sono cambiati molto nel secolo scorso. Certo ci sono stati miglioramenti evolutivi e auto ibride, ma i componenti di base sono gli stessi. Hai un motore, una trasmissione, ecc. Anche le concept car e la tua super costosa Bugatti Veyron sono costruite con la stessa struttura di base. In breve, progettare un'auto è un problema ben noto.

In contrasto con lo sviluppo di software.

  • I clienti non sanno cosa vogliono quando iniziano. Cominciano a parlare di un jet di lusso, ma poi quando si rendono conto dei costi vogliono che tu lo costruisca per il costo di uno scooter a pedali.
  • La progettazione automobilistica impiega anni per passare dall'idea alla concept car e altri anni per arrivare da lì alla produzione. Quando è stata l'ultima volta che hai avuto quel lusso con il software?
  • Le parti di automobili sono pezzi di metallo fuso, ma i componenti software possono cambiare spesso forma e interfaccia.
  • Il processo di fabbricazione è completamente diverso. Con le automobili, i pezzi vengono fabbricati in grandi quantità e gli stessi pezzi vengono utilizzati su veicoli diversi. Con il software quasi tutto è fatto a mano perché altrimenti le cose non vanno bene.

In breve, ci sono una serie di ragioni per cui un'auto sarebbe percepita come "più affidabile" del software. Ho appena avuto un paio.

20
Berin Loritsch

Le auto sono affidabili. Lo stesso vale per la maggior parte dei software.

Ma ... le auto personalizzate e il software personalizzato hanno entrambi i loro problemi.

Qualsiasi vero appassionato di auto, che ha la sua muscle car modificata del 1970, armeggi e modifiche, e ha avarie e tutti i tipi di stupidi problemi che non avrebbe avuto se l'avesse lasciata originale. Ma ... allora non avrebbe avuto il compressore ...

19
CaffGeek

Poiché l'auto che guidi è stata realizzata molte volte, il processo di costruzione è così raffinato che la stessa auto può essere realizzata su una linea di produzione più e più volte.

Se fosse un'auto Edge unica nel suo genere e complessa, costruita da zero una volta che non sarebbe per nulla affidabile, ad esempio guarda quanto è più elevato il tasso di fallimento nelle auto da corsa di formula 1. È comune che uno o due si rompano per gara.

Il nuovo software è sempre una tantum. Ciò che il codice dei programmatori non è mai stato codificato da loro prima. Per ottenere una qualità davvero elevata in questo scenario è necessario un costo proibitivo per la maggior parte dei prodotti. Ogni nuovo software non banale è effettivamente un prototipo.

A parte questo, questo è uno dei motivi principali per cui l'applicazione delle tecniche di ingegneria tradizionali all'ingegneria del software è un disastro.

16
Alb
  1. Le case automobilistiche ottengono in dettaglio tutte le specifiche prima di produrre il prodotto "finale".
  2. Gli utenti di automobili non tendono a fare cose stupide che i progettisti non si aspettavano.
  3. Le auto vengono "aggiornate" solo una volta all'anno (in genere), mentre la maggior parte dei software dovrebbe essere aggiornata più volte all'anno.

Potrei continuare, ma il mio browser sembra che stia per arrestarsi ...

13
Glen Solsberry

C'è in realtà un motivo molto semplice.

Il software che fa soldi è un software che guadagna quote di mercato. Il più delle volte, la società che porta un software sul mercato prima sarà quella che otterrà la maggior parte della quota di mercato, anche se il loro software non è il miglior prodotto nel loro particolare mercato .

Di conseguenza, l'attenzione è rivolta al rilascio del software prima e imperfetto, piuttosto che dopo e perfetto.

10
Robert Harvey

Mi piace la maggior parte delle risposte finora. Ecco il mio giro su di esso.

Il costo per guasto è più grave per le auto rispetto al software

Il fallimento dell'auto potrebbe potenzialmente costare una vita. Anche un guasto al veicolo non pericoloso rappresenta un inconveniente altamente visibile per l'utente. Il fallimento del software significa solo che una povera linfa nel supporto alla produzione dovrà fare gli straordinari. E se quella persona è un dipendente esente a tempo pieno, allora accidenti, non è affatto costoso. In effetti, la scarsa qualità e la cattiva gestione vengono premiate perché gli straordinari gratuiti riducono effettivamente il costo del lavoro all'ora!

Naturalmente, questo dipende dal tipo di software utilizzato (il software che alimenta i sistemi d'arma, i sistemi avionici o medici potrebbe anche avere un effetto sulla vita), ma un'auto costa una buona quantità di denaro e viene utilizzata abbastanza regolarmente che i cali di affidabilità sono abbastanza tangibile e doloroso. Gli errori del software hanno spesso soluzioni alternative.

Un altro pensiero: le auto sembrano affidabili ma hanno costi di manutenzione definiti che sono in corso anche se l'auto funziona bene, e culturalmente, questo è accettato e persino una spesa orgogliosa da parte delle persone che si prendono cura dei loro veicoli. D'altra parte, il software è spesso già rotto quando installato e spesso deve cambiare nel tempo, ma culturalmente, nessuno vuole pagare per la manutenzione.

5
Bernard Dy

Bene, le auto erano piuttosto inaffidabili per gran parte della loro storia, e c'è sicuramente una curva di apprendimento. Le automobili sono state prodotte su larga scala per circa 60 anni, mentre il software è stato prodotto su larga scala per circa 20-25 anni. In larga scala, intendo fondamentalmente abbastanza grande che le masse lo acquistano/lo usano e c'è davvero un grande incentivo per capire come perfezionare la procedura per crearlo.

4
dsimcha

Mi piace pensare all'auto come a un'applicazione. Mentre il sistema operativo è la strada su cui viene eseguita l'applicazione.

L'interfaccia tra strada e auto è ben definita. Ben testato ed è ampiamente verificato per la compatibilità con le versioni precedenti (che è facile in quanto l'interfaccia è semplice). Ma anche così hai alcuni problemi di compatibilità con le versioni precedenti. Le auto di tipo "Farrie" fanno fatica a correre su strade di tipo "strade fangose".

Anche così il tuo sistema operativo, proprio come le strade, necessita di manutenzione costante. Ponti fuori. Le automobili indossano catene da neve e lacerano le strade come un'applicazione corrotta e danneggiano i dischi e i file utilizzati dal sistema operativo.

Le domande saranno scritte su un sistema operativo. Ma in generale devono eseguire diverse versioni del sistema operativo (diversi tipi di strada). Pertanto, l'app ottimizzata per la cena potrebbe funzionare senza problemi e senza problemi purché venga eseguita sul sistema operativo corretto (autostrade), mentre altri codici generici (più semplici) funzioneranno bene su tutti i tipi di strada.

L'interfaccia tra applicazione e sistema operativo è definita ma estremamente complessa e sempre leggermente fluttuante. Soprattutto perché consentiamo all'utente di modificare il proprio sistema operativo con estensioni. Se il governo consentisse agli utenti di modificare le strade ci sarebbero molti più incidenti.

Quando si inizia a limitare la capacità dell'utente di modificare il sistema operativo, l'affidabilità delle applicazioni può diventare quasi solida. Guarda tutti quei dispositivi integrati. Non permettiamo agli utenti di avvicinarsi al proprio sistema operativo e di funzionare correttamente e continuamente 24 ore su 24, 7 giorni su 7, senza interruzione.

Quindi direi che non è quel software inaffidabile. È più come dire che gli utenti stanno scavando buche in autostrada per le applicazioni. Ehi, la tua applicazione si è appena schiantata nel buco che ho scavato l'anno scorso e di cui ho dimenticato.

4
Martin York

Questa è una domanda stupida (non da te, ma dalla persona originale).

Sembra mio padre (un meccanico) che odia i computer e trascorre tutto il giorno su eBay.

È come chiedere "Perché un albero è più affidabile di una falena?".

Prima di tutto, possiedo 30 (sì, 30+) computer e nessuno di loro è stato nel negozio. Ho appena speso $ 1400 per la mia auto nelle riparazioni. Vai a contare il numero di negozi di riparazioni auto vs riparazione computer. Ancora una volta, stupida analogia.

Le auto sono realizzate in acciaio, i computer in plastica. Le auto funzionano in tutte le condizioni atmosferiche, computer progettati per uso interno.

Il mio Commodore 64 (26 anni) funziona perfettamente e non ha avuto riparazioni. Entrambi i miei veicoli (meno di 10 anni) hanno subito riparazioni molto estese. Fammi vedere un'auto con migliaia e migliaia di ore di utilizzo che ha 26 anni e funziona ancora al 100% come quando era nuova di fabbrica.

3
cbmeeks

Innanzitutto, il tuo utente deve sapere che esiste un software così affidabile in questo mondo che non sa nemmeno che esiste. Hai mai visto un incidente TV? Neanche io.

Penso che il motivo principale sia che il software è irrilevante. Essere immateriali significa che i non sviluppatori non vedono i progressi in corso. Ad esempio, se stavo costruendo una macchina, potresti vedermi assemblare le diverse parti e sembrerebbe sempre più una macchina; tuttavia, se mi guardi programmare, forse passerò ore a imprecare contro uno schermo nero con il testo verde che fa strani schemi e poi improvvisamente quando lo schema cambia solo un po 'mi eccito.

Per questo motivo, le persone normali non comprendono la complessità del software. Quando vedono una finestra, pensano di vedere il programma nel suo insieme, il che è davvero così sbagliato.

Inoltre, il software è molto, molto più spesso fortemente personalizzato rispetto alle automobili. Quando personalizzi un'auto, non andrai contro il suo design perché sarebbe visibilmente stupido. Se il mio motore è nella parte anteriore della macchina, spostarlo verso la parte posteriore sarà molto probabilmente un enorme disastro. Tuttavia, poiché il software è irrilevante, se il client ti chiede di fare qualcosa di completamente contrario al design, non riceveranno alcuna indicazione (tranne te, ma non ascolteranno) che quello che stanno facendo è stupido, e poi ' Sarò sorpreso che non funzioni come previsto.

3
zneak
  1. Mancanza di condivisione delle informazioni (i programmatori volano da soli o in piccoli gruppi - i progettisti di auto lavorano con team interconnessi all'interno di una grande azienda e condividono tutte le loro conoscenze; ​​se tutti lavorassimo per le grandi società, saremmo tutti programmatori migliori grazie all'apprendimento dagli altri; questo è anche il motivo per cui cose come programmi open source e risorse online sono molto importanti)
  2. Aspettative dei concorrenti sul campo (va bene se un progettista di auto è solo marginalmente utile per i primi 5-10 anni, ma se un programmatore partecipa a un'intervista e dice che non sarà di grande utilità per 5-10 anni, il l'intervista è finita)
  3. Test di mancanza di penetrazione (a causa della mancanza di fondi, problemi di legalità, ecc .; i produttori di auto, tuttavia, sbattono un'auto dopo l'altra in un muro di mattoni, hanno gallerie del vento, hanno requisiti di prestazione relativamente semplici, ecc.)
  4. Trasparenza delle informazioni (non sai come funziona la maggior parte del software; indovina o fai ipotesi basate su interviste, comunicati stampa, pubblicità, ecc. Con le auto, tuttavia, la maggior parte delle cose è lì per te da guardare)
  5. Inherent Encapsulation of Knowledge (il ragazzo/robot che salda insieme il telaio non ha bisogno di conoscere la matematica alla base del sistema di controllo della stabilità; i programmatori devono essere informati su migliaia o decine di migliaia di cose sconosciute alla persona media, mentre solo i progettisti di auto bisogno di sapere centinaia o migliaia)
  6. Tangibilità (aiuta quando puoi vederlo)
  7. Age of Field (il design del veicolo ha migliaia di anni; il design del veicolo motorizzato ha più di 250 anni [motori a vapore, ecc.])
  8. Criticità dei sottosistemi (le auto continueranno a "funzionare" anche se molte delle loro parti smetteranno di funzionare: blocchi di potenza, alzacristalli elettrici, HVAC, tergicristalli, vetri rotti, coprimozzi persi, pneumatici piatti [inserirne uno nuovo], radio, una luce o due, voce remota, ecc .; quando qualcosa su un computer si rompe, è spesso uno scenario SHTF)
  9. Interdipendenza (quando un computer si rompe, non è raro che colpisca centinaia o migliaia di altri computer; quando un'automobile si rompe, è alquanto raro che siano interessate altre auto - se altre auto sono interessate, è quasi sempre solo 1 -3)
  10. Blanket Blame (se una parte di un computer o un computer su migliaia rompe e danneggia un sistema, la colpa si estende a tutto il computer o, in quest'ultimo caso, all'intera rete di computer; se la tua auto viene colpita da un'auto con freni falliti o se un'auto si ferma e non si riavvia in autostrada, viene biasimata solo la parte dell'auto individuale)
  11. Sistemi finiti contro infiniti (le auto possono avere solo tanto impacchettato e si aspettano di lavorare solo in condizioni limitate, ad esempio non si guida una BMW su un terreno che solo un veicolo simile a una jeep può fare; con computer, tuttavia, le possibilità sono di fatto infinite: ci sono sempre nuove cose, nuove API, nuovi sistemi operativi, nuove falle di sicurezza, iPad, software per telefoni cellulari, novità, novità, ecc.)
  12. Scopo del corpus necessario di conoscenza (una persona con un QI di 130-140 potrebbe imparare quasi tutto quello che c'è da sapere sulle auto, ma potrebbe imparare solo una piccola parte di ciò che c'è da sapere su computer e programmazione)
3
Michael

Il semplice motivo per cui l'intera logica è imperfetta:

I dispositivi meccanici possono essere semplicemente ridotti a Input/Output; l'aumento del numero di parti per ottenere questa operazione I/O non modifica l'operazione I/O. Pertanto, il sistema può essere pienamente compreso.

Il software d'altra parte ha Input -> Process -> Output. Per questa natura il sistema non può essere completamente previsto o compreso.

Donald Rumsfeld l'ha detto meglio:

“Ci sono noti noti; ci sono cose che sappiamo di sapere. Sappiamo anche che ci sono sconosciuti noti; vale a dire sappiamo che ci sono alcune cose che non sappiamo. Ma ci sono anche incognite sconosciute - quelle che non sappiamo non lo sappiamo. "—Segretario alla Difesa degli Stati Uniti Donald Rumsfeld

In sintesi:

  • Un dispositivo meccanico è un sistema che ha conosciuto e conosciuto-sconosciuto,
  • Il software ha quanto sopra ma anche sconosciuti-sconosciuti.
3
Darknight

Il software si basa sui bit: 0 e 1. Le automobili sono basate (principalmente) su parti meccaniche.

Una parte meccanica può usurarsi o non funzionare correttamente e comunque tipo di lavoro. I freni si consumano o una valvola perde, ma l'auto funziona ancora fino a quando non è possibile ripararla.

Il software, per la maggior parte, non ha problemi graduali. Funziona o si rompe. La divisione per zero non è "quasi corretta"; è solo un errore. Quando si tenta di salvare su un'unità senza spazio sufficiente, non è possibile spremere forte per forzare tutti i dati; semplicemente non andrà.

Non penso che il software sia necessariamente meno affidabile di un'auto, ma quando il software fallisce, fallisce immediatamente, non gradualmente.

2
Kyralessa

Le auto in realtà non sono affidabili come pensi. È solo che i guasti possono rimanere nascosti per lungo tempo (o ignorati) senza causare il fallimento dell'intera cosa. La tua auto perde olio e/o liquido di raffreddamento? No? Sei sicuro? Probabilmente ti sbagli ... Probabilmente sta perdendo una piccola quantità da qualche parte che non hai ancora notato ... Ora estendilo alla sospensione, ai pannelli della carrozzeria, agli interni, ecc. Non penso di aver mai ma ho incontrato un'auto con la quale non sono riuscito a trovare qualcosa di sbagliato. Tuttavia, la stragrande maggioranza delle parti è superflua per la missione del trasporto. Non così con un computer. Quasi ogni parte di un computer è fondamentale.

È il vecchio dibattito analogico vs digitale, appena riconfezionato. La TV digitale è fantastica, purché tutto sia perfetto. Nell'istante in cui qualcosa va storto, l'audio balbetta e il video si blocca rendendolo inutile. Confronta con la TV analogica in cui potresti solo avvertire un lieve sibilo o statico che può essere facilmente ignorato.

1
Brian Knoblauch

In primo luogo, naturalmente, alcuni sw sono perfettamente affidabili e le auto - specialmente quelle britanniche e italiane - non sono necessariamente così affidabili.

Detto questo, la mia esperienza di lavoro con il software automobilistico è dovuta a due cose:

  • Costi di garanzia. Quando il tuo sw fallisce, lo riavvii. Forse presenterai una segnalazione di bug. Oppure usa il costoso contratto di assistenza. Quando la tua auto si guasta, la porterai e chiederai che sia riparata in garanzia. Questo costerà al produttore $ 100 e oltre. Se ogni errore di sw costa al produttore $ 2, sono certo che sw sarebbe più affidabile.

  • JD Powers (e altre classifiche di qualità). JD Powers esamina ThingsGoneWrong (che potrebbe essere qualsiasi cosa). E se quella classifica è davvero cattiva, le persone semplicemente non compreranno la tua auto, almeno non per abbastanza soldi per realizzare un profitto. Se avessimo un JD Powers per sw e la gente se ne preoccupasse davvero, allora sono abbastanza sicuro che sw sarebbe più affidabile.

Quindi, se realizzi auto inaffidabili, i costi di garanzia consumeranno rapidamente tutto il tuo profitto e in pochi anni classifiche di cattiva qualità significheranno che non venderai affatto auto. Se effettui sw inaffidabili, gli utenti si lamentano e puoi vendere costosi contratti di supporto.

1
user15497

Non credo che le auto siano meno complesse. Ma anche in questo caso, non credo che il software sia meno affidabile. Tuttavia, credo che ci siano fattori più importanti che portano a discrepanze nell'affidabilità del software:

  1. Astrazione coinvolto nel software. Questo fa sì che i creatori di software non capiscano come funzionano veramente le cose. Col passare del tempo, viene aggiunta sempre più astrazione. Ad esempio, il linguaggio Assembly consente di controllare direttamente la macchina. C è più astratto ma ancora vicino alla macchina. Java, C # e ciò che verrà dopo stanno fortemente astrattando ciò che accade nella macchina. Un altro esempio è se sei un programmatore che vuole capire come avviene la rete a livello di software, quindi dovresti sapere di programmare con C perché l'infrastruttura (come software) è scritta in C.

  2. esperienze diverse e la conoscenza dei produttori porta a risultati diversi. Diversi sviluppatori creano software con diversa affidabilità. Lo stesso si può dire dei produttori di automobili. Tuttavia, la differenza è che chiunque può usare un editor e un compilatore o anche semplicemente installare un IDE (Integrated Development Environment) può creare software e gratuitamente. Per fare una macchina, è necessario un enorme investimento, una fabbrica (alcuni possono fare una macchina senza usarne una ma non la troverai ovunque intorno a te.) Il fatto che tu faccia un grande investimento, significa che proverai ad assumere il meglio sul campo Tuttavia, ci sono ancora problemi di affidabilità con le auto. Se ne sei a conoscenza, molti milioni di auto vengono ritirate dai mercati per gravi [bug]. Nella mia auto, il produttore sostituirà le pinze dei freni gratuitamente per tutte le auto acquistate nello stesso anno. Questo è un problema serio e secondo me mostra che anche le auto non sono affidabili come dice il tuo cliente.

  3. Bug nel software di solito sono più apparenti per gli utenti che per le auto. Questo è il risultato dell'interattività e della risposta tra l'utente e il software. In un'auto, prestiamo attenzione a un minor numero di dettagli come "L'auto sta accelerando quando premiamo il pedale del gas", si rompe, gira, luci, specchi, ecc. Nel software, con ogni clic/input di ogni utente di solito c'è una risposta. Quindi, ci sono molti punti in cui il software può essere difettoso e l'utente lo noterà immediatamente. Questo fa credere all'utente che sia meno affidabile delle auto.

  4. Hacking And Attacks. Più è ampiamente utilizzato un software, maggiore è la percentuale che sarà sotto attacchi di hacking. Puoi confrontarlo con il furto d'auto. Anche per me l'affidabilità di un'auto è compromessa quando può essere aperta da qualcuno diverso dal proprietario o dalla chiave. Tuttavia, è più facile provare ad attaccare il software di un'auto poiché l'attaccante non è visibile. Quindi, quando un software è compromesso, le persone associano che non è affidabile anche se è affidabile per quello per cui è stato creato.

1
Saleh Al-Abbas

L'affidabilità e la sicurezza dei veicoli a motore sono obbligatorie. In molti (la maggior parte?) Paesi è richiesto per legge che abbiano un livello minimo di affidabilità e sicurezza e siano testati per lo scenario peggiore (qualunque cosa sia). Il software commerciale non lo è, per la maggior parte.

Mentre ci sono altre implicazioni legali per il software, è importante notare che se il software si arresta in modo anomalo ogni volta che si preme il pulsante "Salva", si tratta semplicemente di una patch/correzione e si continua. Se un'auto si blocca ogni volta che si accende l'indicatore, allora questa è una cosa molto peggio. Semplicemente non è così importante per Microsoft Outlook funzionare senza crash inaspettatamente come lo è per un SUV da eseguire senza crash inaspettatamente.

Detto questo, ci sono altri software che hanno la stessa o più responsabilità della meccanica di un'auto. Gli aerei e i sistemi di guida missilistica devono essere affidabili; ci sono vite in gioco! Si spera che questi siano testati più rigorosamente rispetto all'automobile media.

1
Anthony

Penso di avere un'analogia molto migliore. Prendi un'azienda che costruisce ambulanze su specifica del cliente. La piattaforma di base (per esempio, un telaio completamente operativo e legale per strade scoperte) richiede modifiche in diversi punti: telaio, sistema di ricarica, beccuccio di riempimento, sospensioni, ecc. soddisfacendo i desideri dei clienti.

Quindi devi costruire il corpo dell'ambulanza stesso, che è anche pieno di requisiti normativi da diversi strati di governo e altri organismi. Pur soddisfacendo al contempo il desiderio del cliente per una disposizione dei posti a sedere funky o un sistema di archiviazione. E non dimenticare che hai un centinaio di clienti diversi da tutto il mondo su diversi piani di acquisto e distribuzione, nessuno dei quali dice mai "Ne prenderò una dozzina in più come l'ultimo" senza inviare anche pagine di eccezioni che spesso richiedono una reingegnerizzazione completa del tutto.

Macchine? È banale. Acquisterai ciò che è costruito e non avrai alcun impatto diretto su qualsiasi aspetto del design. Anche la tua scelta del colore è artificiale perché non puoi effettivamente specificare qualcosa che non è già stato progettato e testato. C'è in un certo senso solo un "mercato", non un "cliente". Direi che i software standardizzati prodotti per alcuni mercati sono generalmente affidabili quanto l'auto che ritiri presso la concessionaria locale.

1
user15456

L'industria automobilistica non rilascia un'auto "beta" al pubblico per i test, l'industria automobilistica non deve preoccuparsi dell'ambiente in cui consegnano i loro prodotti, tuttavia devo preoccuparmi di molte altre cose. dire che l'industria del software è inizialmente sostanzialmente diversa (come tutti sappiamo), quindi affidabilità e complessità sono davvero suggestive. Secondo me un'auto complessa rispetto a un software ma è più facile vedere cosa funziona o meno da allora

  • Nella parte inferiore delle auto non sono virtuali, è destinato a essere più facile da testare (ma più costoso)
  • Hanno iniziato molto prima del settore del software, anche se erano meno persone, non è possibile ridurre al minimo la pratica e le conoscenze acquisite. L'industria del software è ancora un bambino rispetto ad esso.
  • Tutta l'industria automobilistica è vincolata dalla legge e dall'etica a non fare auto che uccide il suo guidatore, specialmente negli ultimi decenni.

Quindi l'affermazione secondo cui il software è meno affidabile delle auto, può essere vera per molti tipi di software e completamente sbagliata per altre aree (sicurezza, aeronautica ...) puoi essere sicuro che un software sia almeno il più affidabile del più affidabile di macchine in quella zona. Semplicemente perché quelle aree sono critiche e da quello che so solo in quelle aree il software può essere paragonato all'industria automobilistica.

Il che ci porta a questo: la maggior parte dei software non è considerata critica nel loro dominio. Se considerato come tale, disponi di un software affidabile, l'unico problema che troverai su questi sono problemi legati all'ambiente (quindi se puoi controllarlo, praticamente non avrai problemi), non il software stesso. Tuttavia la maggior parte dell'editor di software non funziona in queste aree critiche, ovviamente sono tenuti a fornire un certo livello di qualità ma sono più tenuti (a mio avviso) a consegnare il software il prima possibile. Tuttavia, un buon software richiede: una buona gestione del progetto, solide specifiche, un buon design e un buon livello di competenze da parte di coloro che vi lavorano (per riprenderlo). Questo è solo per farlo, non stiamo nemmeno parlando di venderlo ...

Tutto ciò richiede tempo e quindi richiede denaro. Non sto dicendo che ottieni quello che stai pagando per quello che sto dicendo la maggior parte delle volte che produci per cosa investi mai meno (tranne se ti sei fregato ma poi non produci nulla di simile. ..) e qualche volta di più ..

1
lollancf37

Il software è molto più complesso di un'auto, anche se l'auto è composta da migliaia di componenti.

Se un'auto fosse complessa come un software, allora tutti i componenti dell'auto dipenderebbero da tutti gli altri componenti dell'auto e molti componenti dell'auto sarebbero direttamente collegati con molti altri componenti dell'auto.

Tutte le auto del mondo equivalgono a malapena alla complessità del software originale Unix.

0
user15441

È come tutto il resto ... quando funziona non ti interessa ... quando è rotto (o non funziona nel modo che desideri/ti aspetti) ti interessa.

Pensa agli aeroplani. Tonnellate di persone sono preoccupate per le persone che cercano di dirottare o farle esplodere. Ma in realtà il numero di eventi negativi è minuscolo rispetto al numero di voli giornalieri. (Ci sono più voli in un giorno che non siano mai stati dirottati o bombardati ... diamine, anche tentato di essere dirottato o bombardato.)

È tutto dentro dove guardi e come misuri.

0
Matthew Whited

In realtà è abbastanza semplice. Le auto sono vecchie tecnologie. Di sicuro ci sono campane e fischietti in questi giorni (che si rompono) ma se guardi le macchine in anticipo - hanno rotto un lotto.

La "tecnologia" alla base delle parti meccaniche delle automobili è in circolazione da centinaia di anni e anche il motore a combustione interna è in circolazione da molto tempo, e quando sono stati introdotti, c'erano molti problemi.

Considera che i problemi di memoria sono quasi un ricordo del passato con alcune delle nostre piattaforme gestite. Dai al software un paio di centinaia di anni e lo faremo anche inchiodato. In effetti, considerando la complessità del software, penso che siamo in anticipo sulla curva.

0
Steven Evers

Quanti sono i progettisti di automobili? 10.000 in alto? - hanno talento e sanno cosa stanno facendo.

Quanti sono i programmatori di software? 30 milioni? - e molti di loro non hanno idea di cosa stiano facendo, prendiamo ad esempio PHP, puoi imparare PHP e scrivere il tuo primo programma in meno di qualche ora.

Se il software dovesse essere scritto solo da 10.000 dei migliori programmatori, sarebbe affidabile come lo sono le auto.

0
Czarek Tomczak

Le auto moderne si affidano a s/w. Quando le auto moderne falliscono, ad esempio il computer del motore si guasta, di solito (anche se non sempre, ma di solito) l'elettronica che lo ha caricato, non la s/w.

Chiedi a qualsiasi proprietario di un'auto moderna con un ECU per quanto tempo dura prima di un guasto costoso. Sarò sbalordito se avrai 10 anni. Le auto moderne piene di elettronica e sensori sono incredibilmente inaffidabili.

Se studi la teoria dell'affidabilità la risposta diventa accecantemente ovvia. Tutto ciò che è meccanico (si aspettano i software) ha un'affidabilità allo stato stazionario che è il tasso di fallimento al di fuori delle regioni di mortalità infantile e di usura. La percentuale di guasti dell'articolo finale è la SOMMA delle percentuali di guasto delle parti. Aggiungi più parti: il tasso di errore aggregato diventa un numero più alto. La sfida quindi è quella di ottenere tassi di guasto di tutti questi componenti davvero bassi.

Quando si tratta di cose come cinghie dentate e usura dei cilindri e sensori di ossigeno che si riempiono di schifezze e connettori che diventano ohmici e cavi rotti a causa delle vibrazioni, ci sono tecniche che possono essere utilizzate per ridurre il tasso di guasto. Il costo aumenta anche mentre lo fai.

Il software, d'altra parte, ha un tasso di fallimento costante. Nonostante la difficoltà a trovare difetti a volte, alla fine tutto il software è una macchina per insaccare. Ingressi -> Fai cose -> Uscite. A volte l'ORDINE degli ingressi e le combinazioni di ingressi portano a guasti con modalità rilevabili. Quando ciò accade, hai trovato il tuo difetto, lo risolvi e vai avanti.

Il software che non presenta difetti (noti) ha effettivamente un tasso di errore pari a 0. Funzionerà per sempre senza errori. (Tempo medio tra guasti = 1/tasso di guasto). La piattaforma hardware non funzionerà per prima.

Il software con difetti potrebbe funzionare solo fino a quando la giusta combinazione di condizioni di input, nel tempo, non si manifesterà.

La FALLACY in tutto questo è di provare a confrontare i tassi di fallimento di cose fisiche (causati da usura, migrazione dei metalli nei circuiti integrati, ingresso di acqua, vibrazioni, ecc.) Con un tasso di fallimento di ciò che è essenzialmente una macchina a stati finiti che semplicemente fa esattamente ciò che la sua sequenza di istruzioni gli dice di fare.

(Anche cose come le particelle alfa che lanciano bit in RAM è un fenomeno fisico, non un difetto del software. Il modo di gestire un simile uniforme PUO 'tuttavia essere un difetto del software, ma ricorda, che l'alfa cattiva la particella era solo un altro input per il software.)

0
quickly_now

La differenza tra software e automobili è che affinché gli sviluppatori di software mantengano la sanità mentale, i duplicati esatti del software devono essere guidati da tutti gli utenti del software e affinché i produttori di automobili mantengano la sanità mentale, devono accettare che tutti i loro utenti guideranno auto significativamente diverse perché il modo in cui guidi un'auto cambia l'auto, ma il modo in cui usi il software non cambia necessariamente il software.

D'altro canto,

Se avessi un modo per controllare l'olio nel tuo software, sapresti quando fallirà.

Se avessi un modo per cambiare l'olio nel tuo software, probabilmente saresti in grado di prolungarne la durata di alcuni mesi.

E per estendere inutilmente l'analogia:

Le patch non cambiano l'olio, stanno sostituendo una guarnizione che perde.

Gli aggiornamenti non cambiano l'olio, stanno riparando i freni.

Le uscite non cambiano l'olio, sono più come aggiungere un'accensione senza chiave.

0
Peter Turner

Le auto che si rompono non sono tollerabili. Inoltre può mettere in pericolo la vita. I software che presentano guasti sono tollerati e gli utenti lo aggirano o lo accettano. Non c'è molta richiesta di software privo di bug.

Anche il software tende ad essere personalizzato, non hai 10000000 diversi modelli di auto. Direi che Wikimedia è affidabile e tonnellate di ppl usano quel software. Quindi potresti dire che molte persone usano software affidabile o privo di bug. (wordpress, vari controlli del codice sorgente, mysql e sqlite sono abbastanza affidabili, ecc.)

0
user2528

I software sono oggetti matematici e logici, mentre le automobili sono oggetti reali.

Inoltre, puoi facilmente sapere quando un'auto ha un problema e qual è il problema, mentre può essere molto più difficile con i software: immagina qualcuno che ha un problema con un computer e qualcuno che ha un problema con un'auto; questa persona può sapere meglio cosa c'è che non va perché le auto sono meno astratte dei computer.

Non sto dicendo che i computer siano più difficili da capire: le automobili implicano anche molte leggi fisiche come termodinamica, elettronica, chimica.

Potresti anche estrapolare questo confronto, dicendo: "perché un martello è più affidabile di un segretario?".

Non penso che la domanda sia veramente pertinente, ma penso che mostri davvero bene come la mancanza di una buona educazione matematica possa influenzare la comprensione di un certo tipo di sistema.

0
jokoon