Yazılım neden bir araba kadar güvenilir değil? [kapalı]

Bir kullanıcı bana bu soruyu sordu. Arabaların parçalandığını biliyoruz, ancak bunun nedeni fiziksel bir şey (yazılım söz konusu olmadığı sürece!).

Yazılımın çok daha genç bir sektör olduğunu söylemeye çalıştım, ancak kullanıcı "otomobil endüstrisi daha az insanla daha istikrarlı ve güvenilir olmadı mı?"

Ayrıca, yazılımın daha karmaşık olduğunu yanıtlamaya çalıştım, ancak kullanıcı bir araba oluşturan binlerce parça olduğunu söyledi. Araba tasarlayan ve yapan insanlar genellikle bileşenlerini çok iyi tanıyorlar, ancak yine de sonuçta birlikte çalışmaya başladılar.

Peki neden yazılım bir araba kadar güvenilir değil?

Sorunuzun dayanağı basitçe yanlıştır: Yazılım bir arabadan daha az güvenilir değildir. Orada milyarlarca üzerine milyarlarca hiçbir sorunla ucunda yıllarca orada cihazların bu çalışma gömülü yazılım 24x7,. Heck, bir kısmı şunlardır içinde arabalar ve kontrol / motoru izlemek. Peki, otomobillerin kendileri yazılıma güveniyorsa, yazılım bir arabadan daha az güvenilir olabilir?

Yazılım ve mekanik parçalar tasarlarım.

Bu karmaşıklıktır.

Çünkü modern yazılımda milyonlarca "parça" var.

Yazılım parçaları çok karmaşık ve çok fazla DURUM var. Mekanik olmayan hareketli bir parça hiçbir durumda değildir.

Mekanik bir hareketli parça kendi pozisyonuna sahiptir (bir değişken).

1 MB RAM kullanan ve kullanan bir programın bir milyon baytlık durumu vardır. Normal mekanik sistemlerden çok daha fazla durum bu.

Bu kadar nadiren gerçekleştiği için asla test edilmeyen devletlerin bir kombinasyonu olacak. Mekanik bir sistemde (bir araba gibi) mekanik parçaların çalışma sırasında birbirine çarpmadığını kontrol etmek kolaydır. İşyerinde kullandığım mekanik CAD yazılımı otomatik olarak yapıyor.

Makineleri görünmez, dokunulmaz parçalardan inşa ettiyseniz ve hepsi birbirini özleyen milyonlarca hareketli parçaya sahipseniz, basit bir program gibi olurdu.

"Merhaba dünya" bile bir işletim sisteminde çalışıyor. Eski 8 bit sistemler ve minibilgisayar işletim sistemleri oldukça güvenilirdi çünkü basitti.

DLL'ler ve paylaşılan kütüphaneler gibi şeyler virüs güncellemelerinin veya yazılım yüklemelerinin bir parçası olarak değiştirilir ve ardından ilgilenilen program çalışmaz. Aracınızdaki lastiği değiştirmek için bir bisiklet lastiği kullanın. Kütüphane işlevinin kenar durumlarından bazıları karışır (programın beklediği gibi davranmayın).

Nesneler arasında pek çok tasarlanmamış etkileşime izin vermeyen Java gibi dillerde yazılmış programlar (işaretçi yeniden kullanımı, dizi sınırları taşması), onları çalıştırmalarını sağladığınızda genellikle oldukça güvenilirdir.
Statik kütüphanelere sahip işletim sistemlerini kullandığınızda, bir program çalıştıktan sonra çalışmaya devam eder (ancak durum büyüklüğüne bağlı olarak yine de birçok üstün koşullara sahip olacaktır).

Dave Parnas, programın durumunu küçülterek yazılımda güvenilirlik elde etme konusunda yazıyor. Sıkı fonksiyonel programlama adamları tek bir statik atamaya zorlayarak aynı şeyi yapıyorlar.

Bu tüketici seçimi meselesi.

Tüketiciler (benim eski Ford Maverick'in aksine) Honda Civic kadar güvenilir bir yazılım istemişlerdi. Bazı kuruluşlar güvenilir yazılımlar talep eder ve genellikle gömülü yazılımlar için, bazen uzay görevleri ve hava trafik kontrolü gibi güvenlik açısından kritik şeyler için kullanırlar. Yazılım hala mükemmel değil, fakat araba da değil.

Bununla birlikte, müşteriler yazılımlarında başka nitelikler talep ederler ve çoğunlukla daha az işlevsel, kesinlikle daha pahalı ve daha güvenilir olduğu için daha sonra gönderilecek yazılımlar için ödeme yapmak istemezler.

Araba oluşturan binlerce parça var.

Keşke bir bilgisayar (ve ilgili yazılım) bu kadar basit olsaydı.

Bilgisayarın ne kadar büyük bir hafızası var? Milyarlarca terlik mi? Bir terabayt disk mi? Trilyonlarca "hareketli" parça mı?

Yazılımın 10 binlerce veya 100 binlerce binlerce çalışan kod satırı olabilir. Ayrıca, birim testlerinde ve araçlarda bu kadar (veya daha fazla) var.

Hayır. "Arabalar da karmaşık" argümanı ranzadır. Yazılım bir arabadan çok, çok, çok daha karmaşıktır.

Yanmalı motorları yapan prensipler ve bir araba oluşturan tüm bileşenler, geçen yüzyılda pek değişmedi. Elbette evrimsel gelişmeler ve hibrit arabalar oldu, ancak temel bileşenler aynı. Bir motorunuz, bir sürüş treniniz vb. Var. Konsept otomobilleriniz ve süper pahalı son derece hızlı olan Bugatti Veyron, aynı temel yapıya sahip. Kısacası, bir araba tasarımı iyi bilinen bir sorundur .

Bunu, gelişen yazılımla karşılaştırın.

• Müşteriler başladıklarında ne istediklerini bilmiyorlar. Lüks bir jet hakkında konuşmaya başlarlar, ama sonra maliyetleri farkettiklerinde, onu motorlu bir scooter için yapmanı isterler.
• Otomobil tasarımının fikirden konsept otomobire, oradan da üretime geçmesi yıllar alır. En son ne zaman yazılımla bu lüksün içindeydin?
• Araba parçaları, metal döküm parçalarıdır, ancak yazılım bileşenleri sıklıkla şeklini ve arayüzünü değiştirebilir.
• Üretim süreci tamamen farklı. Otomobillerle, parçalar toplu miktarlarda üretilir ve aynı parçalar farklı araçlarda kullanılır. Yazılımla hemen hemen her şey el yapımıdır, çünkü aksi halde şeyler uymaz.

Kısacası, bir arabanın yazılımdan daha "güvenilir" olarak algılanmasının çeşitli nedenleri vardır. Daha yeni bir çift buldum.

Arabalar güvenilir. Bu yüzden çoğu yazılım.

Ama ... özel arabaların ve özel yazılımların kendi sorunları var.

Değiştirilmiş 1970 kas arabasını, tamircilerini ve tweaks'ını taşıyan ve moral bozan her gerçek araba tutkunu ve orijinalini bırakmış olsaydı sahip olamayacağı her türlü aptalca sorunu. Ama ... o zaman süperşarjı olmazdı ...

Sürdüğünüz otomobil birçok kez yapıldığı için, yapım süreci o kadar artar ki aynı otomobil tekrar tekrar bir üretim hattında üretilebilir.

Eğer bir zamanlar sıfırdan inşa edilmiş, benzersiz bir kompleks kesici uçlu araç olsaydı, bir daha güvenilir bir yerde olmazdı, örneğin başarısızlık oranının formül 1 yarış arabalarında ne kadar daha yüksek olduğuna bakın. Bir veya iki kişinin yarış başına parçalanması yaygındır.

Yeni yazılım her zaman bir kereye mahsustur. Programcıların kodları daha önce onlar tarafından kodlanmadı. Bu senaryoda gerçekten yüksek kalite elde etmek, çoğu ürün için yasaklayıcı bir maliyet içerir. Her önemsiz yeni yazılım etkili bir prototiptir.

Bunun yanı sıra, geleneksel mühendislik tekniklerini yazılım mühendisliğine uygulamanın bir felaket olmasının temel nedenlerinden biri de budur.

1. Otomobil üreticileri "nihai" ürünü üretmeden önce tüm özelliklerin çivilenmesini sağlıyor.
2. Otomobil kullanıcıları, tasarımcıların beklemeyeceği aptalca şeyler yapma eğiliminde değiller.
3. Otomobiller yılda bir kez (genellikle) yalnızca "güncellenir", oysa çoğu yazılımın yılda birkaç kez güncellenmesi beklenir.

Devam edebilirdim ama tarayıcım çökmek üzere gibi hissediyor ...

Aslında çok basit bir sebep var.

Para kazandıran yazılım, pazar payını kazanan yazılımdır. Çoğu zaman, piyasaya ilk önce bir yazılım parçası getiren şirket, yazılımı kendi pazarındaki en iyi ürün olmasa bile, pazar payının çoğunluğunu alan şirket olacaktır.

Sonuç olarak, odaklanma yazılımları daha sonradan ve mükemmelden ziyade daha erken ve kusurlu bir şekilde yayınlamaya odaklanmaktır.

Şimdiye kadar cevapların çoğunu seviyorum. İşte benim dönüşüm.

Arıza maliyeti, araçlar için yazılımdan daha ağır

Araba arızası potansiyel olarak bir hayata mal olabilir. Hayatı tehdit edici olmayan bir araç arızası bile, kullanıcı için oldukça görünür bir rahatsızlığı temsil eder. Yazılım hatası, üretim desteğindeki bazı zayıf sapmaların fazla mesai yapmaları gerektiği anlamına gelir. Ve eğer bu kişi tam zamanlı muaf bir çalışansa, o zaman Allah kahretsin, hiç de o kadar pahalı değil. Aslında, düşük kaliteli ve düşük yönetim ödüllendirilir çünkü serbest fazla mesai aslında saatlik işçilik maliyetini düşürür!

Elbette bu, kullanılan yazılımın türüne (silah sistemlerini güçlendiren, aviyonik veya tıbbi sistemler de yaşamları etkileyebilir) bağlıdır, ancak bir araba, çok fazla paraya mal olur ve güvenilirlikle sonuçlanabilecek kadar düzenli kullanılır. oldukça somut ve acı verici. Yazılım hataları genellikle geçici çözümlere sahiptir.

Başka bir düşünce: Arabalar güvenilir görünüyor, ancak araç iyi çalışıyor olsa bile devam eden kesin bakım maliyetlerine sahipler ve kültürel olarak, bu kabul edilir ve hatta araçlarını önemseyen insanlar tarafından yapılan gururlu bir harcama. Diğer taraftan, yazılım yüklendiğinde zaten çoktan bozulmuştur ve zamanla değişmek zorunda kalmaktadır, ancak kültürel olarak, hiç kimse bakım için ödeme yapmak istememektedir.

Arabalar tarihlerinin çoğu için oldukça güvenilmezdi ve kesinlikle bir öğrenme eğrisi var. Otomobiller yaklaşık 60 yıldır geniş çapta üretilirken, yazılımlar yalnızca 20-25 kişilik büyük ölçekte üretilmektedir. Büyük ölçekli olarak, kitlelerin onu satın alması / kullanması için yeterince büyük bir anlam ifade ediyor ve oluşturma prosedürünün nasıl mükemmelleştirileceğini bulmak için gerçekten büyük bir teşvik var.

Aracı bir uygulama olarak düşünmeyi seviyorum. OS ise uygulamanın çalıştığı yoldur.

Yol ve araba arasındaki arayüz iyi tanımlanmıştır. İyi test edilmiştir ve geriye dönük uyumluluk için kapsamlı bir şekilde kontrol edilir (arayüz basit olduğu için kolaydır). Ancak yine de bazı geriye dönük uyumluluk sorunlarınız var. "Farrie" tipi otomobiller, "çamurlu yollar" tipi yollarda koşmakta zorlanırlar.

Öyle olsa bile, tıpkı yollardaki gibi sürekli bakım gerektirir. Köprüler çöktü. Kar zincirlerine takılan arabalar, bozuk veya uygulama gibi yolları yırtıp, işletim sistemi tarafından kullanılan disklere ve dosyalara zarar veriyor.

Başvurular bir işletim sistemine yazılacaktır. Ancak genel olarak işletim sisteminin farklı versiyonlarını (farklı yol türleri) çalıştırmaları gerekir. Böylece, akşam yemeği için optimize edilmiş uygulamanız sorunsuz bir şekilde ve doğru işletim sistemi (Karayolları) üzerinde çalıştığı sürece sorunsuz çalışabilir, diğer genel amaçlı (daha basit) kodlar ise her türlü yolda iyi çalışır.

Uygulama ve İşletim Sistemi arasındaki Arayüz tanımlanır, ancak aşırı derecede karmaşık ve her zaman hafifçe dalgalanır. Özellikle kullanıcının kendi işletim sistemlerini uzantılarla değiştirmesine izin verdiğimizden. Hükümet kullanıcıların yolları değiştirmesine izin verirse, çok daha fazla kaza olur.

Kullanıcının işletim sistemini değiştirme özelliğini sınırlamaya başladığınızda, uygulamaların güvenilirliği neredeyse çok sağlam hale gelebilir. Tüm bu gömülü aygıtlara bakın. Kullanıcılarının işletim sistemlerine yakın bir ortamda ve sizin kesintisiz ve 7/24 kesintisiz çalışmasına izin vermiyoruz.

Bu yüzden güvenilmez bir yazılım olmadığını söyleyebilirim. Daha çok, kullanıcıların uygulamalar için otoyolda delik kazdıklarını söylemek gibi. Hey, başvurunuz geçen yıl kazdığım ve unuttuğum deliğe düştü .

Öncelikle, kullanıcınızın bu dünyada o kadar güvenilir bir yazılım olduğunu bilmesi gerekiyor, bunun farkında bile değil. Hiç televizyon kazası gördün mü? Ben de değil.

Bence asıl sebep, yazılımın önemsiz olmasıdır. Maddi olmayan olmak, geliştiricilerin ilerlemenin devam ettiğini görmemesi anlamına gelir. Mesela bir araba yapıyor olsaydım, beni farklı parçaları birleştirirken görebilirdiniz ve bir arabaya daha çok benzeyecekti; Ancak, eğer programlama bana bakarsanız, belki yeşil metinleri tuhaf desenler yapan siyah bir ekranda küfrederek saatler geçiririm ve sonra da desen biraz değiştiğinde aniden fazla heyecanlanırım.

Bu nedenle, normal insanlar yazılımın karmaşıklığını anlamadılar. Bir pencere gördüklerinde, programı bir bütün olarak gördüklerini düşünüyorlar ki bu çok yanlış.

Ayrıca, yazılım, arabalardan çok, çok daha fazla özelleştirilmiş. Bir arabayı kişiselleştirdiğinizde, tasarımına karşı çıkmazsınız çünkü bu görünüşte aptalca olurdu. Motorum arabanın önünde ise, onu arkaya hareket ettirmek büyük olasılıkla büyük bir felaket olacaktır. Ancak, yazılım önemsiz olduğu için, müşteri tasarıma karşı tamamen bir şey yapmanı isterse, yaptıklarının aptalca olduğuna dair bir gösterge almayacaklar (siz hariç, ama dinlemeyecekler) beklendiği gibi çalışmadığı için şaşırmaya başladım.

1. Bilgi Paylaşımı Eksikliği (programcılar yalnız veya küçük gruplar halinde uçarlar - otomobil tasarımcıları büyük bir şirket içinde birbirine bağlı ekiplerle çalışırlar ve hepsi bilgilerini paylaşırlar; eğer hepimiz büyük şirketler için çalışıyorsak, hepimiz öğrenme nedeniyle daha iyi programcılar olurduk. başkalarından da açık kaynak programlar ve çevrimiçi kaynaklar gibi şeylerin çok önemli olmasının nedeni budur)
2. Sahaya Girenlerin Beklentileri (bir otomobil tasarımcısı yalnızca ilk 5-10 yıl için marjinal olarak faydalıysa sorun yok, ancak bir programcı röportaja girerse ve 5-10 yıl boyunca fazla kullanmayacağını söylüyorsa, röportaj bitti)
3. Penetrasyon Testi eksikliği (fon eksikliği, yasal sorunlar vb. Nedeniyle; otomobil üreticileri, ancak bir tuğla duvara arabadan sonra otomobil çarparak, rüzgar tünellerine sahip, nispeten basit performans gereksinimleri var.)
4. Bilgi Şeffaflığı (çoğu yazılımın nasıl çalıştığını bilmiyorsunuz; röportajlara, basın bültenlerine, reklamlara vb. Dayanarak tahminler yapıyorsunuz ya da tahminler yapıyorsunuz; arabalarla, ancak işlerin çoğunluğu bakmanız için orada.)
5. Bilginin Doğasında Kapsüllenmesi (çerçeveyi birbirine bağlayan adam / robotun stabilite kontrol sisteminin arkasındaki matematiği bilmesi gerekmez; programcılar ortalama bir kişi için bilinmeyen binlerce veya onbinlerce şey hakkında bilgili olmalıdır, oysa ki otomobil tasarımcıları sadece yüzlerce veya binlerce kişi bilmeli
6. Netlik (görebildiğiniz zaman yardımcı olur)
7. Alan Yaşı (araç tasarımı binlerce yaşında; motorlu araç tasarımı 250 yaşın üzerinde [buhar motorları vb.])
8. Altsistemlerin Kritikliği (otomobiller parçaları çoğu çalışmayı bıraksa bile yine de "çalışacak" - elektrikli kilitler, elektrikli camlar, HVAC, ön cam silecekleri, kırık camlar, kayıp jant kapağı, patlak lastikler [yeni bir tane koy], radyo, hafif ya da iki uzaktan giriş, vs.; bilgisayardaki bir şey bozulduğunda, genellikle bir SHTF senaryosudur)
9. Birbirine bağımlılık (bir bilgisayar bozulduğunda, yüzlerce veya binlerce bilgisayarı etkilemesi nadir değildir; bir araba bozulduğunda diğer arabaların etkilenmesi biraz nadirdir - diğer araçlar etkilenirse, neredeyse her zaman sadece 1 -3)
10. Battaniye Suçu (bir bilgisayarın bir parçası veya binlerce kişiden biri bir bilgisayarı kırar ve bir sistemi incitirse, suçlama tüm bilgisayara ya da ikinci durumda tüm bilgisayar ağına yayılırsa; Arızalı frenler veya bir araba durursa ve karayolu üzerinde yeniden çalışmaya başlamazsa, sadece bireysel otomobil parçası suçlanır)
11. Sonlu ve Sonsuz sistemler (arabalar yalnızca çok fazla paketlenmiş olabilir ve yalnızca sınırlı koşullar altında çalışması beklenir - örneğin, yalnızca bir Cip benzeri aracın yapabileceği bir arazi üzerinde bir BMW sürmezsiniz; bununla birlikte, olasılıklar fiilen sonsuzdur - her zaman yeni şeyler var, yeni API'ler, yeni işletim sistemleri, yeni güvenlik delikleri, iPad'ler, cep telefonu yazılımı, bu yeni, yeni, vb.)
12. Gereken Bilgi Kapsamının Kapsamı (130-140 IQ'ya sahip bir kişi, otomobiller hakkında neredeyse her şeyin öğrenilebileceğini ancak bilgisayar ve programlama hakkında bildiklerinin bir kısmını öğrenebilir)

Tüm mantığın hatalı olmasının basit nedeni:

Mekanik cihazlar Giriş / Çıkış'a kolayca düşürülebilir ; Bu G / Ç işlemini gerçekleştirmek için parça sayısının arttırılması G / Ç işlemini değiştirmez. Böylece sistem tamamen anlaşılabilir.

Yazılımın diğer taraftan Girdi -> İşlem -> Çıktı vardır . Bu nitelik nedeniyle sistem tam olarak tahmin edilemez veya anlaşılamaz.

Donald Rumsfeld en iyisini söyledi:

“Bilinen şeyler var; bildiğimiz bildiğimiz şeyler var. Ayrıca bilinen bilinmeyenler olduğunu biliyoruz; yani bilmediğimiz bazı şeyler olduğunu biliyoruz. Ama bilinmeyen bilinmeyenler de var - bilmediklerimiz bilmediğimizi. ”- Amerika Birleşik Devletleri Savunma Sekreteri Donald Rumsfeld

Özetle:

• Mekanik bir cihaz, bilinen ve bilinmeyen bir sistemdir,
• Yazılım yukarıda da bilinmeyen bilinmeyenlere sahiptir.

Bu aptalca bir soru (sizden değil, asıl kişiden).

Bu, bilgisayarlardan nefret eden babam (tamirci) gibi görünüyor, ancak bütün gün eBay'de geçiriyor.

"Neden bir ağaç bir güveden daha güvenilir?"

Her şeyden önce, 30 (evet, 30+) bilgisayarım var ve bunlardan biri dükkanda değildi. Arabama 1400 dolar harcadım. Bilgisayar onarımı vs oto tamirhanelerinin sayısını say. Bir kez daha aptal analoji.

Arabalar çelikten, bilgisayarlardan plastik. Arabalar her türlü hava koşulunda çalışır, iç mekan kullanımı için tasarlanmış bilgisayarlar.

Commodore 64 (26 yaşında) mükemmel çalışıyor ve onarımı olmadı. Her iki aracım da (10 yaşından küçük) çok kapsamlı bir onarım geçirdi. Bana binlerce yaşında, 26 yaşında olan ve fabrika yeniyken yaptığı gibi hala% 100 çalışan bir araba göster.

Yazılım bitlere dayanmaktadır: 0 ve 1. Otomobiller (çoğunlukla) mekanik parçalara dayanmaktadır.

Mekanik bir parça aşınabilir veya arızalanabilir ve yine de bir nevi iş yapabilir. Frenleriniz aşınmış veya bir valf sızdırıyor, ancak araç hala onarıncaya kadar çalışır.

Yazılım, çoğunlukla, aşamalı başarısızlık gibi bir şeye sahip değildir. Çalışır ya da kırılır. Sıfıra bölmek "neredeyse doğru" değildir; bu sadece bir hata. Yeterli alan olmadan bir sürücüye kaydetmeye çalıştığınızda, içindeki tüm verileri zorlamak için sıkıştıramazsınız; Sadece gitmeyecek.

Yazılımın bir arabadan daha az güvenilir olduğunu düşünmüyorum, ancak yazılım başarısız olduğunda, yavaş yavaş değil, hemen arızalı.

Sanırım çok daha iyi bir benzetme var. Müşteri isteğine göre ambulanslar kuran bir şirket alın. Temel platform (örneğin tamamen işlevsel ve sokak yasal bir RV kesit şasisi) birkaç noktada modifikasyon gerektirir: çerçeve, şarj sistemi, doldurma ağzı, süspansiyon vb. müşteri isteklerini tatmin ederken.

O zaman, çeşitli hükümet katmanları ve diğer organların düzenleyici gereklilikleriyle dolu ambulans organını kendisi kurmalısınız. Müşteri hala tatmin edici olsa da bazı korkak oturma düzeni veya depolama sistemi için arzu. Unutmayın ki, dünyanın dört bir yanından yüzlerce farklı müşteriye sahip olduğunuzu unutmayın; bunların hiçbiri "Birincisi gibi bir düzine daha fazla alacağım" demedi. Sık sık her şeyin tamamen yeniden yapılandırılmasını gerektirir.

Arabalar? Bu önemsiz. İnşa edilenleri satın alacaksınız ve tasarımın hiçbir yönü üzerinde doğrudan bir etkiye sahip değilsiniz. Renk seçiminiz bile yapaydır, çünkü henüz tasarlanmamış ve test edilmemiş bir şeyi belirtemezsiniz. Bir anlamda 'müşteri' değil, sadece 'pazar' var. Bazı pazarlar için üretilmiş hazır yazılımların, genellikle yerel satıcıda aldığınız araç kadar güvenilir olduğunu savunuyorum.

Arabalar aslında sandığınız kadar güvenilir değil. Sadece hatalar, her şeyin başarısız olmasına neden olmadan uzun süre gizli kalabiliyor (ya da yok sayılıyor). Arabanızda yağ ve / veya soğutucu sızıntısı var mı? Hayır? Emin misiniz? Muhtemelen yanılıyorsunuz ... Muhtemelen henüz farketmediğiniz bir yerde çok az miktarda sızıntı yapıyor ... Şimdi bunu süspansiyona, gövde panellerine, iç kısma, vb. Kadar uzatın. henüz yanlış bir şey bulamadığım bir arabaya rastladım. Bununla birlikte, parçaların büyük çoğunluğu nakliye görevine gereksizdir. Öyle bir bilgisayar değil. Bir bilgisayardaki hemen hemen her parça önemlidir.

Eski analog vs dijital tartışma, sadece yeniden paketlendi. Dijital TV her şey mükemmel olduğu sürece mükemmeldir. Anında bir şeyler ters giderse, ses çalar ve video onu gereksiz kılar. Kolayca görmezden gelinen biraz tıslayan ya da statik olan analog TV ile karşılaştırın.

Öncelikle elbette bazı yazılımlar tamamen güvenilirdir ve otomobiller - özellikle İngiliz ve İtalyanlar - mutlaka güvenilir değildir.

Bu, otomotiv yazılımı ile çalışma deneyimimin iki şeye indiği yönünde olduğunu söyledi:

• Garanti masrafları. Sw'iniz başarısız olduğunda yeniden başlatın. Belki de bir hata raporu vereceksin. Veya pahalı destek sözleşmesini kullanın. Aracınız arızalandığında, onu devreye sokacak ve garanti kapsamında sabitlenmesini talep edeceksiniz. Bu yapımcıya 100 $ ve üzerinde bir ücret ödeyecek. Her sw başarısızlık yapıcı 2 $ maliyeti ise ben sw eminim sw daha güvenilir olacaktır.

• JD Powers (ve diğer kalite sıralamaları). JD Powers ThingsGoneWrong'u (ki bu herhangi bir şey olabilir) araştırıyor. Ve eğer bu sıralama gerçekten kötüyse, insanlar arabanı almayacaklar, en azından kar elde etmek için yeterli para için. Eğer sw için bir JD Powers'ımız vardı ve insanlar buna değer veriyorsa, sw'in daha güvenilir olacağından eminim.

Bu nedenle, güvenilir olmayan otomobiller yaparsanız, garanti maliyetleri hızlı bir şekilde tüm kazancınızı tüketir ve birkaç yıl içinde kötü kalite dereceleri hiç araba satmayacağınız anlamına gelir. Güvenilmez sw yaparsanız, kullanıcılar şikayet edecek ve pahalı destek sözleşmeleri satıyor olacaksınız.

Motorlu Taşıt güvenilirliği ve güvenliği zorunludur. Pek çok (en?) Ülkede yasaların asgari güvenilirlik ve güvenlik seviyelerine sahip olmaları gerekir ve en kötü senaryo için test edilirler (ne olursa olsun). Ticari yazılım, çoğu zaman değildir.

Yazılım için başka yasal uygulamalar olsa da, "Kaydet" düğmesine her bastığınızda yazılımın çökmesi durumunda, bunun sadece bir yama / düzeltme meselesi olduğunu ve devam etmeye devam edeceğinizi not etmek önemlidir. Göstergeyi her açtığınızda bir araba çarpıyorsa, bu çok daha kötü bir şeydir. Microsoft Outlook'un beklenmedik bir şekilde çökmeden çalışması, o kadar da SUV'un beklenmedik bir şekilde çökmeden çalışması gerektiği kadar önemli değil.

Söylendiği gibi, bir arabanın mekaniğinden daha fazla veya daha fazla sorumluluğu olan başka yazılım parçaları var. Uçaklar ve Füze Rehberlik sistemleri güvenilir olmalı; tehlikede hayatlar var! Biri bunların ortalama motorlu arabaya göre daha sıkı test edilmesini umuyordu.

Otomobil endüstrisi, test için halka bir "beta" otomobil yayınlamamaktadır, otomobil endüstrisi, ürünlerini teslim ettikleri ortam konusunda da endişelenmek zorunda kalmamakta, ancak diğer birçok konuda endişelenmem gerekiyor. Yazılım endüstrisinin ilk önce temelde farklı olduğunu (hepimizin bildiği gibi), bu nedenle güvenilirlik ve karmaşıklık gerçekten anlamlıdır. Bence bir yazılımdan daha karmaşık bir araba ama o zamandan beri neyin işe yarayıp yaramadığını görmek daha kolay

• Arabaların altındaki sanal değil, test etmek daha kolay olacak (ancak daha pahalı)
• Yazılım endüstrisinden çok daha önce başladılar, daha az insan olsalar bile, topladıkları uygulama ve bilgileri en aza indiremezsiniz. Yazılım endüstrisi hala buna göre bir bebek.
• Tüm otomobil endüstrisi, özellikle son on yılda sürücülerini öldüren bir otomobil yapmamak için yasa ve etik kurallara tabidir.

Bu nedenle, yazılımın araçlardan daha az güvenilir olduğunu söyleyen, birçok tür yazılım için doğru olabilir ve diğer alan için tamamen yanlış olabilir (güvenlik, havacılık ...) bir yazılımın en azından en güvenilirinden daha güvenilir olduğundan emin olabilirsiniz. Bu bölgedeki arabaların. Basitçe, bu alanlar kritik olduğundan ve sadece o alandaki yazılımda bildiklerimden otomobil endüstrisi ile karşılaştırılabilir.

Bu da bizi buna yönlendirir: çoğu yazılım kendi alanlarında kritik öneme sahip değildir. Bu şekilde düşünüldüğünde, güvenilir bir yazılıma sahip olursunuz, bunlar hakkında bulacağınız tek sorun çevreye bağlı problemlerdir (yani eğer kontrol edebiliyorsanız, neredeyse hiç sorun yaşamayacaksınız), yazılımın kendisi. Bununla birlikte, çoğu yazılım editörü bu kritik alanda çalışmaz, elbette belirli bir kalite seviyesi sağlamaları zorunludur, ancak yazılımı mümkün olan en kısa sürede sunmaları daha zorlayıcıdır (bence). Bununla birlikte, iyi bir yazılım gerektirir: iyi proje yönetimi, sağlam özellikler, iyi tasarım ve içinde çalışanlardan iyi düzeyde beceri (devam etmek için). Bu sadece yapmak için, satmaktan bile bahsetmiyoruz ...

Bunların hepsi zaman alıyor ve bu yüzden para gerektiriyor. Çok az bir zaman için yatırım yaptığınızı ürettiğinizde söylediklerinizin parasını aldığınızı söylemiyorum (mahvolmadığınız ancak o zaman hiçbir şey üretmediğiniz hariç) ve bazen daha fazlası. .

Arabaların daha az karmaşık olduğuna inanmıyorum. Ancak bu durumda bile, yazılımın daha az güvenilir olduğunu sanmıyorum. Ancak, yazılımın güvenilirliğinde tutarsızlıklara yol açan daha önemli faktörlerin olduğuna inanıyorum:

1. Yazılım ile ilgili soyutlama . Bu, yazılım yaratıcılarının işlerin gerçekten nasıl yürüdüğünü yanlış anlamalarına neden olur. Zaman geçtikçe, daha fazla soyutlama eklenir. Örneğin, Assembly dili size makineyi doğrudan kontrol etmenizi sağlar. C daha soyutlanmış fakat yine de makineye yakın. Java, C # ve sonra ne gelecek, makinede olanları çok soyutlıyor. Diğer bir örnek ise, ağ üzerinde yazılımın nasıl oluştuğunu anlamak isteyen bir programcıysanız, altyapı (C) olarak yazıldığından C ile programlamayı bilmelisiniz.

2. Farklı deneyimlerYapımcıların bilgisi ve farklı sonuçlara yol açar. Farklı Geliştiriciler, farklı güvenilirliğe sahip yazılımlar oluşturur. Aynısı Araba üreticileri için de söylenebilir. Ancak fark, bir editör ve derleyici kullanabilen ve hatta bir IDE (Integrated Development Environment) yükleyebilen herhangi birinin ücretsiz ve ücretsiz yazılım oluşturabilmesidir. Bir araba yapmak için, büyük bir yatırıma, bir fabrikaya ihtiyacınız var (bazıları kullanmadan bir araba yapabilir, ancak etrafınızda her yerde bulamazsınız). Büyük bir yatırım yapmanız gerçeği, bu alanda en iyisini işe almaya çalışacağınız anlamına gelir. Ancak, otomobillerde hala güvenilirlik sorunları var. Eğer bunun farkındaysanız, milyonlarca otomobil ciddi hatalar için piyasalardan çekiliyor. Otomobilimde, üretici aynı yılda satın alınan tüm araçlar için fren makaslarını ücretsiz olarak değiştirecek.

3. Yazılımdaki hatalar genellikle kullanıcılar için araçlardan daha belirgindir. Bu, kullanıcı ve yazılım arasındaki etkileşimin ve yanıtın sonucudur. Bir otomobilde, "Gaz pedalına basarken otomobil hızlanıyor", kırma, dönme, lambalar, aynalar, vb. Gibi daha az ayrıntıya dikkat ediyoruz. Yazılımda, her kullanıcının tıklama / giriş ile genellikle cevap. Bu nedenle, yazılımın sorunlu olabileceği ve kullanıcının hemen fark edeceği birçok nokta vardır. Bu, kullanıcıyı arabalardan daha az güvenilir olduğuna inandırıyor.

4. Hacking And Saldırıları . Bir yazılım ne kadar yaygın kullanılırsa, bilgisayar korsanlığı saldırılarına maruz kalma oranı o kadar yüksek olur. Bunu araba hırsızlığıyla karşılaştırabilirsiniz. Bana göre aynı zamanda bir araç güvenilirliği, sahibi veya anahtarı dışında biri tarafından açılabildiğinde tehlikeye girer. Ancak, saldırganın görünmediğinden yazılım saldırmaya çalışmak bir arabadan daha kolaydır. Bu nedenle, bir yazılım tehlikeye girdiğinde, insanlar ne için yapıldığı konusunda güvenilir olmasına rağmen güvenilir olmadığını ilişkilendirir.

Her şey gibi ... umursamadığın zaman ... kırıldığı zaman (ya da istediğin / beklediğin gibi çalışmadığında) umursuyorsun.

Uçakları düşünün. Tonlarca insan, onları kaçırmaya veya havaya uçurmaya çalışan insanlar için endişeleniyor. Ancak gerçekten olumsuz olayların sayısı, günlük uçuşların sayısına göre çok küçük. (Bir gün içinde daha fazla uçuş var, o zaman kaçırıldı ya da bombalandı .. heck kaçırılmaya ya da bombalanmaya çalışıldı bile.)

Hepsi içeriye bakıyordun ve nasıl ölçüyordun.

Aslında oldukça basit. Arabalar eski teknolojidir. Tabi bu günlerde zil ve ıslık var (bu kırılma) ama erken arabalara bakarsanız - çok kırıldılar .

Otomobillerin mekanik parçalarının ardındaki 'teknoloji' yüzlerce yıldır ve içten yanmalı motor da uzun süredir var ve tanıtıldıklarında birçok sorun vardı.

Bellek sorunlarının, yönetilen platformlarımızın bazıları ile neredeyse geçmişte kaldığını düşünün. Yazılım birkaç yüz yıl verin ve biz de çivilenmiş olacak. Aslında, yazılımın karmaşıklığı göz önüne alındığında, biz eğrinin önünde olduğumuzu düşünüyorum.

Modern otomobil s / w güveniyor. Modern otomobiller arıza yaptığında, örneğin motor bilgisayarı arızalandığında, genellikle (her zaman olmasa da, genellikle) damlayan elektronik aksam, s / w değil.

Herhangi bir ECU'lu modern bir arabanın sahibine, pahalı bir arızadan önce ne kadar süre çalıştırıldığını sorun. 10 yıl alırsan sersemlerim. Elektronik ve sensörlerle dolu modern arabalar şaşırtıcı derecede güvenilmez.

Güvenilirlik teorisini okursanız cevap açıktır. Mekanik olan her şey (beklenen yazılım), bebek ölümleri ve yıpranma bölgelerinin dışında kalan arıza oranı olan kararlı bir güvenilirliğe sahiptir. Son maddenin başarısızlık oranı, parçaların başarısızlık oranlarının TOPLAMI'dır. Daha fazla parça ekleyin: toplam arıza oranı daha yüksek bir sayı olur. O zaman asıl zorluk, tüm bu bileşenlerin arıza oranlarının gerçekten düşük olmasını sağlamak.

Triger kayışları ve silindir aşınması ve oksijen sensörlerinin saçmalıklarla dolması, konektörlerin omik yanması ve titreşim nedeniyle kırılması gibi şeyler söz konusu olduğunda, arıza oranını azaltmak için kullanılabilecek teknikler vardır. Maliyet de bunu yaptığınız gibi artar.

Öte yandan, yazılım sabit bir arıza oranına sahiptir. Zaman zaman kusur bulma zorluğuna rağmen, sonunda tüm yazılım bir sosis makinesidir. Girişler -> Öğeleri yapın -> Çıkışlar. Bazen girişlerin SİPARİŞİ ve girişlerin kombinasyonları algılanabilir modlarda başarısızlığa yol açar. Bu olduğunda, kusurunu buldun, tamir ettin ve devam ediyorsun.

Bilinen bir kusuru olmayan yazılımlar etkin bir şekilde 0 başarısızlık oranına sahiptir. Sonsuza dek hatasız çalışacaktır. (Arızalar Arasındaki Ortalama Süre = 1 / başarısızlık oranı). Önce donanım platformu başarısız olur.

Kusurlu yazılımlar ancak zaman içinde girdi koşullarının doğru birleşimi, kusurun ortaya çıkmasına neden olana kadar çalışabilir.

Tüm bunlardaki GÜZELLİK, fiziksel şeylerin (yıpranma, IC'lerde metal göçü, su girişi, titreşim vb.) Başarısızlık oranlarını esasen tam olarak yapan bir sonlu durum makinesinin başarısızlık oranıyla karşılaştırmaktır. komut dizisinin yapmasını söylediği şey.

(RAM'de bitleri ters çeviren alfa parçacıkları gibi şeyler bile bir yazılım arızası değil fiziksel bir fenomendir. Böyle bir eşitliği ele alma şekli bir yazılım hatası olabilir, ancak kötü alfa parçacığının yazılıma başka bir girdi olduğunu unutmayın. )

Yazılım ve otomobiller arasındaki fark, yazılım geliştiricilerin akıl sağlığını koruyabilmesi için, yazılımın tüm kopyalarının yazılımın tüm kopyaları tarafından sürülmesi ve otomobil üreticilerinin akıl sağlığını korumak için tüm kullanıcılarının araç kullanacağını kabul etmeleri gerektiğidir. önemli ölçüde farklı otomobiller, çünkü araba kullandığınız yol otomobili değiştirir, ancak yazılımı kullanma şekliniz mutlaka yazılımı değiştirmez.

Diğer yandan,

Yazılımınızdaki yağı kontrol etmenin bir yolu olsaydı, ne zaman başarısız olacağını bilirdiniz.

Yazılımınızdaki yağı değiştirmenin bir yolu olsaydı, muhtemelen ömrünü birkaç ay uzatabilirsiniz.

Ve analojiyi anlamsızca genişletmek için:

Yamalar yağı değiştirmiyor, sızdıran contayı değiştiriyorlar.

Güncellemeler yağı değiştirmiyor, frene basıyorlar.

Bültenler yağı değiştirmiyor, anahtarsız bir ateşleme eklemek gibi.

Yıkılan otomobiller tolere edilemez. Ayrıca yaşamları tehlikeye atabilir. Bozulmaya tolere edilen yazılımlar ve kullanıcılar bunun üzerinde çalışır veya sadece kabul eder. Hatasız bir yazılım için çok fazla talep yok.

Ayrıca yazılımın kişiselleştirilmesi de 10000000 farklı araba modeline sahip değil. Wikimedia'nın güvenilir olduğunu ve ppl'nin bu yazılımı kullandığını söyleyebilirim. Böylece birçok insanın hatasız veya güvenilir yazılım kullandığını söyleyebiliriz. (wordpress, çeşitli kaynak kontrolü, mysql ve sqlite oldukça güvenilirdir, vb.)

Yazılımlar matematiksel ve mantıksal nesnelerdir, arabalar ise gerçek nesnelerdir.

Dahası, bir otomobilin ne zaman bir problemi olduğunu ve sorunun ne olduğunu kolayca öğrenebilirsiniz, bununla birlikte yazılımlarda çok daha zor olabilir: bir bilgisayarda bir problemi olan birini ve bir arabada problemi olan birini hayal edin; bu kişi neyin yanlış olduğunu daha iyi anlayabilir çünkü arabalar bilgisayarlardan daha az soyuttur.

Bilgisayarların anlaşılmasının zor olduğunu söylemiyorum: Arabalar ayrıca termodinamik, elektronik, kimya gibi birçok fiziksel yasa içermektedir.

Ayrıca, "neden bir çekiç sekreterden daha güvenilirdir?" Diyerek bu karşılaştırmayı tahmin edebilirsin.

Sorunun gerçekten alakalı olduğunu sanmıyorum, ancak iyi bir matematik eğitiminin olmayışının belli bir sistem anlayışını nasıl etkileyebileceğini çok iyi gösterdiğini düşünüyorum.

Binlerce bileşenden oluşsa bile, yazılım bir otomobilden çok daha karmaşıktır.

Bir otomobil yazılım kadar karmaşık olsaydı, o zaman tüm otomobil bileşenleri otomobilin tüm diğer bileşenlerine bağlı olacaktı ve pek çok otomobil bileşeni diğer pek çok otomobil bileşeniyle doğrudan bağlantılı olacaktı.

Tüm dünya otomobilleri, orijinal Unix yazılımını karmaşıklıkla eşittir.