ソフトウェアが車ほど信頼できないのはなぜですか？
ユーザーにこの質問をしてもらいました。私たちは車が故障することを知っていますが、それは物理的な何かのためです（ソフトウェアが関与しない限り！）.
私はソフトウェアははるかに若い業界だと答えようとしましたが、ユーザーは「自動車業界はより少ない人々でより安定して信頼できるようになったのではないか」と反論しました。
私はまた、ソフトウェアはより複雑であると答えようとしましたが、ユーザーは自動車を構成する部品が何千もあると反論しました。自動車の設計と製造を行う人々は、一般的にコンポーネントを非常によく知っていますが、最終的にはすべて一緒に作業することになります。
では、ソフトウェアが車ほど信頼できないのはなぜですか？
あなたの質問の前提は単に正しくありません。ソフトウェアは自動車ほど「信頼性が低い」わけではありません。問題なく何年にもわたって24時間年中無休で組み込みソフトウェアを実行するデバイスは数十億億あります。ヘック、その一部はin車であり、エンジンを制御/監視します。では、自動車自体がソフトウェアに依存している場合、ソフトウェアは自動車よりも信頼性が低いのでしょうか。
ソフトウェアや機械部品の設計をしています。
それは複雑さです。
なぜなら、現代のソフトウェアには何百万もの「パーツ」があるからです。
ソフトウェアパーツは非常に複雑で、状態がたくさんあります。機械的な非可動部品には状態がありません。
機械的な可動部分には、その位置があります（1つの変数）。
1MbのRAM=を使用するプログラムは、100万バイトの状態を持っています。これは、通常の機械システムよりはるかに多くの状態です。
まれにしか発生しないため、テストされない状態の組み合わせがあります。自動車などの機械システムでは、動作中に機械部品が互いにぶつからないことを簡単に確認できます。機械式CAD仕事で使用するソフトウェアは、自動的にそれを行います。
目に見えない、触れられない部品から機械を構築し、何百万もの可動部品がすべて互いに欠けている場合、それは単純なプログラムのようになります。
「hello world」でさえ、オペレーティングシステム上で実行されます。古い8ビットシステムとミニコンピュータオペレーティングシステムは、シンプルであるため、かなり信頼できました。
DLLや共有ライブラリなどは、ウイルスの更新やソフトウェアのインストールの一部として置き換えられ、対象のプログラムが機能しなくなります。車のタイヤを自転車のタイヤに交換するようなものです。ライブラリ関数の一部のEdge状態が干渉します（プログラムが期待する方法で動作しないでください）。
Javaのような言語で書かれたプログラムは、オブジェクト間の多くの未設計の相互作用（ポインタの再利用、配列の境界のオーバーフロー）を許可しない）は、いったんそれらを動作させると、通常はかなり信頼できます。
静的ライブラリを備えたオペレーティングシステムを使用する場合、いったんプログラムが機能すると、プログラムは機能し続けます（ただし、状態のサイズに基づいて、多くのEdge条件が引き続き存在します）。
Dave Parnasは、プログラムの状態を小さくすることでソフトウェアの信頼性を高めることについて書いています。厳密な関数型プログラミングの人たちは、単一の静的割り当てを強制することによって同じことをしています。
それは消費者の選択の問題です。
消費者が（私の古いフォードマーベリックとは対照的に）私のホンダシビックと同じくらい信頼できるソフトウェアを要求した場合、それはそうなります。一部の組織は、信頼性の高いソフトウェアを要求し、それは、通常、組み込みソフトウェア、場合によっては宇宙ミッションや航空管制などの安全が重要なもののために得られます。ソフトウェアはまだ完全ではありませんが、どちらも車ではありません。
ただし、顧客はソフトウェアに他の品質を要求し、ほとんどの場合、機能が低く、確かに高価であり、信頼性が高いという理由だけで出荷されるソフトウェアを購入することを望んでいません。
車を構成する何千もの部品があります。
コンピュータ（および関連するソフトウェア）だけがそれほど単純だったとしたら。
コンピュータには何ギガバイトのメモリがありますか？何十億ものフリップフロップ？テラバイトのディスク？何兆もの「動く」部品？
ソフトウェアでは、数万または数十万の個別のコード行が実行されている場合があります。それに加えて、単体テストとツールの数が多くなります。
いいえ。「車も複雑」という議論は二段です。ソフトウェアは自動車よりはるかに複雑です。
燃焼エンジンを機能させる原理、および自動車を構成するすべてのコンポーネントは、過去1世紀においてあまり変わっていません。確かに進化的な改良とハイブリッドカーがありましたが、基本的なコンポーネントは同じです。エンジンやドライブトレインなどがあります。コンセプトカーや非常に高価な非常に高速なブガッティヴェイロンも、同じ基本構造で構築されています。つまり、車の設計はよく知られている問題です。
ソフトウェアの開発とは対照的です。
- 顧客は、開始したときに何が欲しいかわからない。彼らは高級ジェット機について話し始めますが、彼らがコストに気づいたとき、彼らはあなたが足で動くスクーターのコストのためにそれを構築することを望んでいます。
- カーデザインは、アイデアカーからコンセプトカーに至るまでには数年かかり、そこから製造されるまでにはさらに数年かかります。ソフトウェアでこれほど贅沢をしたのはいつですか？
- 自動車部品は金属の鋳造部品ですが、ソフトウェアコンポーネントは形状やインターフェースを頻繁に変更する可能性があります。
- 製造工程は全く異なります。自動車の場合、部品は大量生産され、同じ部品がさまざまな車両で使用されます。ソフトウェアを使用すると、ほとんどすべてが手作業で作成されます。
手短に言えば、自動車がソフトウェアよりも「信頼性が高い」と認識される理由はいくつかあります。カップルを思いついたところです。
車は信頼できます。ほとんどのソフトウェアもそうです。
しかし...カスタムカーとカスタムソフトウェアの両方に問題があります。
1970年のマッスルカーを改造し、いじくり回し、微調整し、故障したり、元の状態のままにしておくと発生しなかったあらゆる種類の愚かな問題を抱える実際の自動車愛好家。しかし...その後、彼は過給機を持っていません...
あなたが運転する車は何度も製造されているため、建設プロセスは非常に洗練されており、同じ車を何度も生産ラインで製造することができます。
ゼロから構築された、他に類を見ない複雑なカッティングエッジカーである場合、信頼性が低くなる可能性があります。たとえば、F1レーシングカーの故障率がどれほど高いかを見てください。レースごとに1つまたは2つが故障するのが一般的です。
新しいソフトウェアは常に一度限りです。プログラマがコーディングするものは、これまで彼らによってコーディングされたことはありません。このシナリオで本当に高品質を得るには、ほとんどの製品にとって法外なコストがかかります。重要な新しいソフトウェアはすべて、事実上プロトタイプです。
余談ですが、これは、従来のエンジニアリング手法をソフトウェアエンジニアリングに適用することが障害となる主な理由の1つです。
- 自動車メーカーは、「最終的な」製品を生産する前に、仕様全体を明確にします。
- 自動車ユーザーは、デザイナーが予想しなかった愚かなことをする傾向はありません。
- 自動車は年に1回（通常）のみ「更新」されますが、ほとんどのソフトウェアは年に何度も更新されることが予想されます。
続行できますが、ブラウザがクラッシュしそうな感じです...
実際には非常に単純な理由があります。
お金を稼ぐソフトウェアは、市場シェアを獲得するソフトウェアです。たいていの場合、ソフトウェアを市場に投入する会社firstは、ソフトウェアが特定の市場で最高の製品ではない場合でも、市場シェアの過半数を獲得する会社になります。
そのため、ソフトウェアを後で完全にリリースするのではなく、より早く完全にリリースすることに重点が置かれています。
これまでの答えのほとんどが好きです。ここに私のスピンがあります。
故障のコストは、ソフトウェアよりも自動車の方が深刻です
車の故障は潜在的に命を落とす可能性があります。生命を脅かす車両の故障でさえ、ユーザーにとって非常に目に見える不便さを表します。ソフトウェア障害は、生産サポートの一部の樹液が残業しなければならないことを意味します。そして、その人がフルタイム免除の従業員であれば、まあ、それはまったく高価ではありません。実際、無料の残業は実際に1時間あたりの人件費を削減するため、質の悪さと管理の悪さが報われます。
もちろん、これは使用しているソフトウェアの種類によって異なります（武器システム、航空電子機器、医療システムに電力を供給するソフトウェアも生命に影響を与える可能性があります）が、車にはかなりの費用がかかり、信頼性が失われるほど定期的に使用されますかなり具体的で苦痛です。多くの場合、ソフトウェア障害には回避策があります。
別の考え：車は信頼できるように見えますが、車がうまく機能していても継続的に維持される確かなメンテナンスコストがあり、文化的にはこれは受け入れられており、車を気遣う人々によって誇り高い支出さえされています。一方、ソフトウェアはインストール時にすでに壊れていることが多く、時間の経過とともに変化することがよくありますが、文化的には誰もメンテナンスの費用を負担したくありません。
まあ、車は彼らの歴史のほとんどのためにかなり信頼できなかった、そして確かに学習曲線があります。自動車は約60年間大規模に生産されてきましたが、ソフトウェアは約20〜25年間だけ大規模に生産されました。大規模とは、基本的に、大衆がそれを購入/使用するのに十分な大きさであることを意味し、それを作成する手順を完成させる方法を理解するための本当に大きなインセンティブがあります。
私は車をアプリケーションとして考えたいです。 OSはアプリケーションが実行される道です。
道路と車の間のインターフェースは明確に定義されています。十分にテストされており、下位互換性について広範囲にわたってチェックされています（インターフェースがシンプルなので簡単です）。しかし、それでも、いくつかの下位互換性の問題があります。 「ファリー」タイプの車は、「マッドロード」タイプの道路を走るのに苦労します。
それでも、道路と同じようにOSには継続的なメンテナンスが必要です。橋は出ます。車はスノーチェーンを装着し、アプリケーションが壊れるように道路を引き裂き、OSが使用するディスクとファイルに損傷を与えます。
アプリケーションは1つのOSで作成されます。ただし、一般的には、異なるバージョンのOS（異なるタイプの道路）を実行する必要があります。そのため、適切なOS（高速道路）で実行されていれば、夕食用に最適化されたアプリは問題なくスムーズに実行できますが、他の汎用（より単純な）コードはあらゆるタイプの道路で正常に実行できます。
アプリケーションとOS間のインターフェイスは定義されていますが、非常に複雑で、常にわずかに変動します。特に、ユーザーが自分のOSを拡張機能で変更できるようになっているためです。政府がユーザーに道路の修正を許可した場合、さらに多くのクラッシュが発生するでしょう。
OSを変更するユーザーの機能を制限し始めると、アプリケーションの信頼性はほぼ確実になります。これらすべての組み込みデバイスを見てください。私たちは、OSの近くにいるユーザーに、中断なく24時間年中無休で問題なく稼働することを許可しません。
だから私はそれが信頼できないソフトウェアではないことを言うでしょう。ユーザーが高速道路のアプリケーション用の穴を掘っていると言っているようなものです。 アプリケーションが昨年私が掘り起こして忘れた穴にぶつかったね。
これは愚かな質問です（あなたからではなく、元の人から）。
これは、コンピューターを嫌いながらも一日中eBayに費やしている私の父（整備士）のようです。
「なぜ木は蛾より信頼できるのか」と尋ねるようなものです。
まず第一に、私は30台（はい、30台以上）のコンピュータを所有していますが、そのうちの1台は店舗にありませんでした。私は車の修理に$ 1400を費やしました。自動車修理店とコンピュータ修理店の数を数えます。もう一度、愚かなアナロジー。
車はスチール製、コンピューターはプラスチック製です。車はあらゆる気象条件で動作し、室内用に設計されたコンピューターです。
私のコモドール64（26歳）は完璧に動作し、修理も行っていません。私の車は両方とも（10年未満の）非常に広範囲な修理を受けています。何千時間も何千時間も使用されている26歳の自動車で、工場出荷時と同じように100％走行しています。
まず、ユーザーはこの世界に信頼性の高いソフトウェアが存在することさえ知らないほどソフトウェアが存在することを知る必要があります。テレビのクラッシュを見たことがありますか？私もダメ。
主な理由は、ソフトウェアが重要でないためだと思います。重要ではないということは、開発者以外の人が進行状況を見ていないことを意味します。たとえば、私が車を作っている場合、さまざまな部品を組み立てて、それがますます車のように見えるのを見ることができます。しかし、プログラミングを見てみると、奇妙なパターンを実行している緑のテキストが表示された黒い画面で何時間も呪いをかけ、突然パターンが少しだけ変化すると、私は興奮しすぎます。
そのため、一般の人々はソフトウェアの複雑さを理解していません。窓を見ると、プログラム全体を見ていて、まあまあです。
また、ソフトウェアは自動車よりもはるかに頻繁にカスタマイズされています。あなたが車をカスタマイズするとき、それは目に見えて愚かであるため、あなたはそのデザインに反対することはありません。私のエンジンが車の前にある場合、それを後ろに移動することはおそらく大災害になるでしょう。ただし、ソフトウェアは重要ではないので、クライアントが設計に対して完全に何かをするように求めた場合、彼らがしていることは愚かであることが示されません（あなたを除いて、彼らは聞きません）。期待どおりに動作しないことに驚いてしまいます。
- 情報共有の欠如（プログラマーは単独または小グループで飛行します-自動車設計者は大企業内の相互に接続されたチームと協力し、彼ら全員が知識を共有します。私たち全員が大企業で働いていれば、学習により全員がより優れたプログラマーになるでしょう他人から;これはまた、オープンソースプログラムやオンラインリソースのようなものが非常に重要である理由でもあります）
- フィールドエントラントへの期待（自動車設計者が最初の5〜10年間はほんのわずかしか役に立たなくても大丈夫ですが、プログラマーがインタビューに出て5〜10年間あまり役に立たないと言った場合、インタビュー終了）
- 侵入テストの欠如（資金不足、合法性の問題などが原因です。ただし、自動車メーカーは、自動車をレンガの壁にぶつけたり、風洞を設けたり、比較的簡単な性能要件を持っているなど）
- 情報の透明性（ほとんどのソフトウェアがどのように機能するかはわかりません。面接、プレスリリース、広告などに基づいて推測または推測を行います。ただし、自動車の場合、ほとんどのものがそこにあります）
- 固有の知識のカプセル化（フレームを溶接している人/ロボットは、安定性制御システムの背後にある数学を知る必要はありません。プログラマーは、平均的な人に知られていない何千、何万ということについて知識がなければなりません数百または数千を知る必要がある）
- 触知性（あなたがそれを見ることができるときに役立ちます）
- エイジオブフィールド（車両の設計は数千年前、電動車両の設計は250年以上前のものです[スチームエンジンなど]）
- サブシステムの重要性（パワーロック、パワーウィンドウ、HVAC、フロントガラスワイパー、壊れたウィンドウ、紛失したハブキャップ、パンクしたタイヤ[新しいものに交換]、ラジオ、 1つまたは2つのリモートエントリなど、コンピューター上の何かが壊れた場合、それは多くの場合SHTFシナリオです）
- 相互依存関係（1台のコンピューターが故障しても、他の数百または数千のコンピューターが影響を受けることはまれではありません。1台の車が故障すると、他の車が影響を受けることはまれです-他の車が影響を受ける場合、ほとんど常に1のみです。 -3）
- 全面非難（コンピューターの一部または数千のうちの1つのコンピューターが壊れてシステムに損害を与えた場合、非難はコンピューター全体、または後者の場合はコンピューターのネットワーク全体に及びます。車がブレーキが故障した場合、または車が失速して高速道路で再起動しない場合は、個々の車のパーツのみが原因です）
- 有限システムと無限システム（自動車は非常に多くの荷物を積むことができるだけであり、限られた条件下でのみ動作することが期待されています-たとえば、ジープのような自動車だけができる地形でBMWを運転することはありません。コンピューターでは、ただし、可能性は事実上無限です。常に新しいもの、新しいAPI、新しいOS、新しいセキュリティホール、iPad、携帯電話のソフトウェア、これ、これなどがあります。）
- 必要な知識の範囲（IQ 130-140の人は、自動車について知っていることのほとんどすべてを学ぶことができますが、コンピュータとプログラミングについて知っていることのほんの一部しか学ぶことができませんでした）
ロジック全体に欠陥がある単純な理由：
機械装置は、単純にInput/Output;に削減できます。このI/O操作を実現するためにパーツの数を増やしても、I/O操作は変わりません。したがって、システムを完全に理解することができます。
一方、ソフトウェアには入力->プロセス->出力があります。この性質のため、システムを完全に予測または理解することはできません。
ドナルドラムズフェルドはそれを最もよく言った：
「既知の既知のものがあります。私たちが知っていることがあります。また、既知の未知数があることも知っています。つまり、わからないことがいくつかあるということです。しかし、未知の未知数もあります–未知の未知数です。 」—米国国防長官ドナルドラムズフェルド
要約：
- 機械装置とは、既知および未知のシステムであり、
- ソフトウェアには上記のものがありますが、未知の未知数もあります。
ソフトウェアはビットに基づいています：0および1。車は（主に）機械部品に基づいています。
機械部品は、摩耗したり故障したりする可能性があります。ブレーキが摩耗したり、バルブが漏れたりしますが、車は修理するまでほとんど機能します。
ほとんどの場合、ソフトウェアには段階的な障害などの問題はありません。機能するか、壊れます。ゼロによる除算は「ほとんど正しい」ではありません。それは単なるエラーです。十分なスペースがないドライブに保存しようとすると、すべてのデータを強制的に押し込むことができません。それは行きません。
ソフトウェアは必ずしも自動車よりも信頼性が低いとは思いませんが、ソフトウェアが故障すると、徐々にではなくすぐに故障します。
車はあなたが思っているほど実際には信頼できません。障害は、全体を失敗させることなく、長期間（または無視して）非表示のままにできるというだけのことです。あなたの車はオイルやクーラントを漏らしていますか？番号？本気ですか？あなたはおそらく間違っている...それはおそらくあなたがまだ気づいていないどこかでほんの少しの量を漏らしているだけだ...さて、それをサスペンション、ボディパネル、インテリアなどに拡張してください。まだ何かが見つからない車に出会った。ただし、パーツの大部分は輸送の任務に不必要です。コンピュータではそうではありません。コンピュータのほぼすべての部分が重要です。
これは古いアナログ対デジタルの議論であり、再パッケージされたばかりです。すべてが完璧である限り、デジタルTVは素晴らしいです。何かがうまくいかなかった瞬間、音声が途切れ、ビデオがブロックされ、役に立たなくなります。簡単に無視できるわずかなヒスノイズまたはスタティックノイズが発生するアナログTVと比較してください。
まず最初に、もちろん一部のSWは完全に信頼でき、自動車（特にイギリスとイタリアの自動車）は必ずしもそれほど信頼できるとは限りません。
とはいえ、自動車用ソフトウェアを扱う私の経験は、次の2つに帰着するということです。
保証費用。 swが失敗した場合、再起動します。おそらくあなたはバグレポートを提出するでしょう。または、高価なサポート契約を使用します。あなたの車が故障したとき、あなたはそれを持ち込み、保証の下で修理されることを要求します。これはメーカーに100ドル以上の費用がかかります。 swの失敗ごとにメーカーに2ドルの費用がかかる場合、swの方が信頼性が高いと私は確信しています。
JD Powers（およびその他の品質ランキング）。 JD Powersは、ThingsGoneWrong（何でもかまいません）を調査します。そして、そのランキングが本当に悪いなら、人々は単にあなたの車を買わないでしょう、少なくとも利益を上げるのに十分なお金のために。私たちにswのJDパワーがあり、人々が本当に気にかけているなら、swの方が信頼性が高いと確信しています。
したがって、信頼性の低い車を製造すると、保証コストによって利益がすぐになくなり、数年後には品質のランクが悪くなるため、車をまったく販売できなくなります。信頼性の低いswを作成すると、ユーザーは不満を抱き、高価なサポート契約を売ることになります。
車はそれほど複雑ではないと思います。しかし、そうであっても、ソフトウェアの信頼性が低いとは思いません。ただし、ソフトウェアの信頼性の不一致につながるより重要な要因があると思います。
抽象化ソフトウェアに関与。これにより、ソフトウェア作成者は物事が実際にどのように機能しているかを誤解します。時間の経過とともに、ますます抽象化が追加されます。たとえば、アセンブリ言語を使用すると、マシンを直接制御できます。 Cはより抽象化されていますが、まだマシンに近いです。 Java、C＃、そして次に何が起こるかは、マシンで何が起こるかを大きく抽象化しています。もう1つの例は、ソフトウェアレベルでネットワーキングがどのように行われるかを理解したいプログラマである場合、インフラストラクチャ（ソフトウェアとして）がCで記述されているため、Cでプログラミングすることを知っている必要があります。
異なる体験そして、メーカーの知識は異なる結果につながります。開発者が異なれば、信頼性の異なるソフトウェアが作成されます。自動車メーカーについても同じことが言えます。ただし、違いは、エディターとコンパイラーを使用したり、IDE（統合開発環境）をインストールしたりすることさえできる）誰でもソフトウェアを無料で作成できることです。車を作るには、莫大な投資、工場（一部はそれを使用せずに車を作ることができますが、あなたの周りのどこにでもそれを見つけることはできません。） 。しかし、それでも車には信頼性の問題があります。ご存知の場合、数百万台の車が深刻な[バグ]のために市場から撤退しています。私の車では、購入したすべての車のメーカーがブレーキクリッパーを無料で交換します同じ年にこれは深刻な問題であり、私の意見では、車でさえクライアントの言うほど信頼性が高くないことがわかります。
ソフトウェアのバグ通常、ユーザーは自動車よりも外観が優れています。これは、ユーザーとソフトウェア間の対話性と応答の結果です。車では、「アクセルペダルを踏んだときに車が加速している」、壊れている、曲がっている、ライト、ミラーなどの少ない詳細に注意を払っています。ソフトウェアでは、ユーザーがクリック/入力するたびに、応答。したがって、ソフトウェアにバグがある可能性があり、ユーザーがすぐに気付く点がたくさんあります。これにより、ユーザーは自動車よりも信頼性が低いと考えています。
ハッキングと攻撃。ソフトウェアが広く使用されるほど、ハッキング攻撃を受ける割合が高くなります。これを車の盗難と比較できます。私にとっても、所有者またはキー以外の誰かが車を開けられると、車の信頼性が損なわれます。ただし、攻撃者が見えないため、車よりもソフトウェアを攻撃する方が簡単です。そのため、ソフトウェアが侵害された場合、その目的は信頼できるとしても、信頼できないと人々は言います。
自動車の信頼性と安全性が義務付けられています。多くの（ほとんどの？）国では、最低限の信頼性と安全性が法律で義務付けられており、最悪のシナリオ（それが何であれ）についてテストされています。ほとんどの場合、商用ソフトウェアはそうではありません。
ソフトウェアには他にも法的な影響がありますが、[保存]ボタンを押すたびにソフトウェアがクラッシュする場合は、パッチ/修正の問題であり、続行することに注意してください。インジケーターをオンにするたびに車がクラッシュする場合、これははるかに悪いのことです。 SUVが予期せずにクラッシュすることなく実行されるため、Microsoft Outlookが予期せずにクラッシュせずに実行されることはそれほど重要ではありません。
そうは言っても、自動車のメカニズムと同じかそれ以上の責任を持つソフトウェアは他にもあります。飛行機とミサイル誘導システムは信頼できるものでなければなりません。危機に瀕している命があります！これらは、平均的な自動車よりも厳格にテストされることを望みます。
私はもっと良いアナロジーを持っていると思います。顧客の仕様に合わせて救急車を建設する会社を例に挙げましょう。基本プラットフォーム（たとえば、完全に動作し、街路法に基づくRV切断可能シャーシ）では、フレーム、充電システム、フィラースパウト、サスペンションなど、いくつかの点で変更が必要です。これらの変更は、街路法的であるだけでなく、管轄区域の要件を満たす必要があります顧客の要望を満足させながら。
次に、救急車本体を構築する必要があります。これには、政府やその他の団体のいくつかの層からの規制要件も伴います。ファンキーな座席配置またはストレージシステムに対する顧客の要望は引き続き満たしています。また、世界中から100の異なる購入および導入スケジュールの顧客がいることを忘れないでください。例外のページを送信することなく、「最後の顧客と同じように、さらに1ダースかかる」と言う人はいません。多くの場合、全体の完全なリエンジニアリングが必要です。
車？それは取るに足らないことです。ビルドされたものを購入し、デザインのどの側面にも直接的な影響はありません。まだ設計およびテストされていないものを実際に指定することはできないため、色の選択でさえ人工的なものです。ある意味では「市場」だけが「顧客」ではありません。一部の市場向けに開発された既製のソフトウェアは、一般に、地元の販売店で購入する車と同じくらい信頼できると主張します。
自動車業界は「ベータ」車をテストのために一般にリリースしていません。自動車業界も、製品を出荷する環境を心配する必要はありませんが、私は他にも多くのことを心配する必要があります。つまり、ソフトウェア業界は最初は根本的に異なる（誰もが知っているように）ので、信頼性と複雑さは本当に示唆的だと言います。私の意見では、車はソフトウェアよりも複雑ですが、何が機能しているかを確認するのは簡単です
- 車の底部は仮想ではないため、テストが容易になるはずです（ただし、より高価です）。
- 彼らはソフトウェア業界よりもずっと早くスタートしました。たとえ彼らが少なかったとしても、彼らが集めた実践と知識を最小限に抑えることはできません。ソフトウェア業界はまだそれと比べるとまだ赤ん坊です。
- すべての自動車産業は法律と倫理に拘束されており、特に過去数十年間、ドライバーを殺す車を作らないようにしています。
したがって、ソフトウェアは車よりも信頼性が低く、多くの種類のソフトウェアに当てはまり、他の領域（セキュリティ、航空など）には完全に間違っている可能性があるというステートメントは、ソフトウェアが少なくとも最も信頼性が高いことよりも信頼性が高いことを確認できますそれらの地域の車の。これらの領域が重要であり、私がそれらの領域でのみ知っていることから、ソフトウェアが自動車産業と比較できるからです。
これが私たちをこれに導いてくれます：ほとんどのソフトウェアは彼らのドメインで重要であると考えられていません。このように考えると、信頼できるソフトウェアがあり、それらに見られる唯一の問題は環境に関連する問題です（したがって、それを制御できれば、実質的に問題はありません）。ソフトウェア自体ではありません。ただし、ほとんどのソフトウェアエディターはこれらの重要な領域で動作しません。もちろん、一定の品質を提供することはできますが、ソフトウェアをできるだけ早く提供することは（私の意見では）より制限されます。ただし、優れたソフトウェアには、優れたプロジェクト管理、堅固な仕様、優れた設計、それに携わっている人からの（再開のための）優れたスキルが必要です。それはそれを作るためだけのものであり、私たちはそれを売ることについてさえ話していません...
これにはすべて時間がかかるため、費用がかかります。あなたが生産するほとんどの時間、私が言っていることに対してあなたが払っているものをあなたが得ると言っているわけではありませんあなたが投資するもの決して少なくならない..）そして時々もっと..
たとえ自動車が何千ものコンポーネントで構成されていても、ソフトウェアは自動車よりもはるかに複雑です。
自動車がソフトウェアのように複雑である場合、自動車のすべてのコンポーネントは自動車の他のすべてのコンポーネントに依存し、多くの自動車コンポーネントは他の多くの自動車コンポーネントと直接リンクされます。
世界のすべての車は、元のUnixソフトウェアとほとんど同じくらい複雑ではありません。
それは他のすべてのような...それが機能するときあなたは気にしない...それが壊れたとき（またはあなたが望む/期待どおりに機能しないとき）あなたは気にかける.
飛行機について考えてください。何千人もの人々がハイジャックや爆破を試みている人々を心配しています。しかし、実際には、負のイベントの数は、毎日のフライトの数と比較するとごくわずかです。 （1日にさらに多くのフライトがあり、その後ハイジャックまたは爆撃されたことがあります。ハイジャックまたは爆撃されようと試みさえしました。）
見た目と測定方法はすべて完了です。
それは実際には非常に簡単です。車は古い技術です。確かに最近は（壊れる）鈴と笛がありますが、初期の車を見るとlotが壊れています。
自動車の機械部品の背後にある「テクノロジー」は何百年も前から存在しており、内燃エンジンも古くから存在し、それらが導入されたとき、多くの問題がありました。
一部の管理対象プラットフォームでは、メモリの問題はほとんど過去のものであると考えてください。ソフトウェアに数百年を与えると、ソフトウェアも釘付けにされます。実際、ソフトウェアの複雑さを考えると、私たちは時代の先を行っていると思います。
車のデザイナーは何人いますか？ 10,000トップ？ -彼らは才能があり、彼らが何をしているかを知っています。
ソフトウェアプログラマーは何人ですか？ 3000万？ -そして、彼らの多くは彼らが何をしているのかわからない、例えばPHPプログラマーをとると、PHPを学ぶことができ、最初のプログラムを数時間。
ソフトウェアが最高のプログラマの1万人だけで書かれるとしたら、自動車と同じくらい信頼できるでしょう。
現代の車はソフトウェアに依存しています。現代の車が故障した場合、たとえばエンジンコンピューターが故障した場合、通常は（常にではありませんが、通常は）電子機器がそれを破壊しました。ソフトウェアではありません。
ECUが入っている現代の車の所有者に、高価な故障が発生するまでの実行時間を尋ねてください。10年経つと驚かされます。電子機器とセンサーが満載の現代の車は驚くほど驚異的です信頼できない。
信頼性理論を研究すれば、答えは盲目的に明白になります。すべての機械的（ソフトウェアを期待する）は、幼児の死亡率と摩耗領域の外での故障率である定常状態の信頼性を持っています。最終品目の故障率は、部品の故障率の合計です。部品を追加してください：全体的な故障率が高くなります。その場合の課題は、これらすべてのコンポーネントの故障率を本当に低くすることです。
タイミングベルトやシリンダーの摩耗、酸素センサーががらくたになる、コネクターがオーミックになる、振動が原因でワイヤーが断線するなどのことになると、故障率を下げるために使用できる手法があります。これを行うと、コストも上昇します。
一方、ソフトウェアの故障率は一定です。時々欠陥を見つけることは困難ですが、結局のところ、すべてのソフトウェアはソーセージマシンです。入力->実行->出力。入力の順序と入力の組み合わせによって、検出可能なモードで障害が発生する場合があります。それが起こるとき、あなたはあなたの欠陥を見つけました、あなたはそれを修正して、あなたは次に進みます。
（既知の）欠陥のないソフトウェアの故障率は事実上0です。故障することなく永久に実行されます。 （平均故障間隔= 1 /故障率）。ハードウェアプラットフォームが最初に失敗します。
欠陥のあるソフトウェアは、時間の経過とともに入力条件の正しい組み合わせによって欠陥が明らかになるまでしか実行されない可能性があります。
これらすべての誤りは、物理的なものの故障率（摩耗、IC内の金属の移動、水の侵入、振動などによって引き起こされる）を、本質的に有限状態機械である故障率と比較することです。その命令シーケンスが何をするように指示するか。
（RAMでビットを反転するアルファ粒子のようなものでも、物理的な現象であり、ソフトウェアの欠陥ではありません。このような偶数を処理する方法は、ソフトウェアの欠陥である可能性がありますが、厄介なアルファパーティクルはソフトウェアへのもう1つの入力でした。）
ソフトウェアと車の違いは、ソフトウェア開発者が健全性を維持するためには、ソフトウェアの正確な複製がソフトウェアのすべてのユーザーによって駆動されなければならず、自動車メーカーが健全性を維持するためには、すべてのユーザーが運転することを受け入れる必要があるということです車の運転方法によって車が変わるため、車は大きく異なりますが、ソフトウェアの使用方法によってソフトウェアが変わるとは限りません。
一方、
ソフトウェアのオイルをチェックする方法があったら、いつ失敗するかがわかります。
ソフトウェアのオイルを変更する方法があったら、おそらく数ヶ月で寿命を延ばすことができるでしょう。
そして、類推を無意味に拡張するには：
パッチはオイルを交換するのではなく、漏れのあるガスケットを交換します。
アップデートはオイルを変えるのではなく、ブレーキを修理しています。
リリースはオイルを変えるものではなく、キーレス点火を追加するようなものです。
故障した車は許容できません。また、生命を危険にさらす可能性があります。故障したソフトウェアは許容され、ユーザーはそれを回避するか、そのまま受け入れます。バグのないソフトウェアに対する需要はあまりありません。
また、ソフトウェアはカスタマイズされる傾向があり、10000000の異なるモデルの車はありません。ウィキメディアは信頼性が高く、たくさんのPPLがそのソフトウェアを使用していると思います。したがって、多くの人がバグのないソフトウェアまたは信頼性の高いソフトウェアを使用していると言えます。 （ワードプレス、さまざまなソース管理、mysqlおよびsqliteはかなり信頼できるなど）
ソフトウェアは数学および論理オブジェクトであり、自動車は実際のオブジェクトです。
さらに、車に問題がある場合、問題は何であるかを簡単に知ることができますが、ソフトウェアの場合ははるかに困難になる可能性があります。車はコンピュータほど抽象的ではないため、この人は何が悪いのかをよりよく理解できます。
コンピュータは理解が難しいと言っているのではありません。自動車には、熱力学、電子工学、化学などの多くの物理法則も含まれています。
また、「なぜハンマーの方が秘書より信頼性が高いのか」と言って、この比較を推定することもできます。
質問はそれほど関連性があるとは思いませんが、良い数学教育の欠如が特定の種類のシステムの理解にどのように影響を与えることができるかを本当によく示していると思います。