Yazılım hatası -Software bug

Wikipedia'da bir MediaWiki hatasını bildirmek için Wikipedia:Hata raporları bölümüne bakın .

Bir serinin parçası
Yazılım geliştirme
Çekirdek aktiviteleri
Paradigmalar ve modeller
Metodolojiler ve çerçeveler
Destekleyici disiplinler
Uygulamalar
Araçlar
Standartlar ve Bilgi Organları
sözlükler
Anahatlar
Bir serinin parçası
Bilgi Güvenliği
Kategorilere Göre Bilgi Güvenliği Olayları, 2014 Mali Yılı.svg
İlgili güvenlik kategorileri
tehditler
Savunmalar

Bir yazılım hatası , bir bilgisayar programında veya sisteminde , yanlış veya beklenmeyen bir sonuç üretmesine veya istenmeyen şekillerde davranmasına neden olan bir hata, kusur veya arızadır. Hataları bulma ve düzeltme süreci " hata ayıklama " olarak adlandırılır ve genellikle hataları saptamak için resmi teknikler veya araçlar kullanır ve 1950'lerden beri bazı bilgisayar sistemleri, işlemler sırasında çeşitli bilgisayar hatalarını caydırmak, algılamak veya otomatik olarak düzeltmek için tasarlanmıştır.

Hataların çoğu, bir programın tasarımında veya kaynak kodunda ya da bu tür programlar tarafından kullanılan bileşenlerde ve işletim sistemlerinde yapılan hatalardan ve hatalardan kaynaklanır . Birkaçına yanlış kod üreten derleyiciler neden olur. Çok sayıda hata içeren ve/veya işlevselliğini ciddi şekilde engelleyen hatalar içeren bir programın buggy (arızalı) olduğu söylenir . Hatalar, dalgalanma etkileri olabilecek hataları tetikleyebilir . Hataların ince etkileri olabilir veya programın çökmesine veya bilgisayarın donmasına neden olabilir. Diğer hatalar güvenlik hataları olarak nitelendirilir ve örneğin, kötü niyetli bir kullanıcının yetkisiz ayrıcalıklar elde etmek için erişim kontrollerini atlamasını sağlayabilir .

Bazı yazılım hataları felaketlerle ilişkilendirilmiştir. Therac-25 radyasyon tedavisi makinesini kontrol eden koddaki hatalar , 1980'lerde hasta ölümlerinden doğrudan sorumluydu. 1996 yılında, Avrupa Uzay Ajansı'nın 1 milyar ABD Doları tutarındaki prototip Ariane 5 roketi, araçtaki rehberlik bilgisayar programındaki bir hata nedeniyle fırlatıldıktan bir dakika sonra imha edilmek zorunda kaldı. Haziran 1994'te Kraliyet Hava Kuvvetleri'ne ait bir Chinook helikopteri Mull of Kintyre'ye çarparak 29 kişiyi öldürdü. Bu başlangıçta pilot hatası olarak reddedildi, ancak Computer Weekly tarafından yapılan bir araştırma Lordlar Kamarası soruşturmasını bir yazılım hatasından kaynaklanmış olabileceğine ikna etti . uçağın motor kontrol bilgisayarında .

2002'de ABD Ticaret Bakanlığı'nın Ulusal Standartlar ve Teknoloji Enstitüsü tarafından yaptırılan bir araştırma , "yazılım hataları veya hataları o kadar yaygın ve o kadar zararlı ki, ABD ekonomisine yılda yaklaşık 59 milyar dolara, yani yaklaşık 0.6 milyar dolara mal oluyor" sonucuna vardı. Gayri safi yurtiçi hasılanın yüzdesi".

Tarih

Ana madde: Hata (mühendislik)

Orta İngilizce kelime bugge , bir canavar için kullanılan terimler olarak " bugbear " ve " bugaboo " terimlerinin temelidir .

Kusurları tanımlamak için kullanılan "hata" terimi, 1870'lerden beri mühendislik jargonunun bir parçası olmuştur ve elektronik bilgisayarlar ve bilgisayar yazılımlarından daha eskidir; başlangıçta donanım mühendisliğinde mekanik arızaları tanımlamak için kullanılmış olabilir. Örneğin, Thomas Edison 1878'de bir iş arkadaşına yazdığı mektupta şu sözleri yazmıştı:

Bütün icatlarımda böyle olmuştur. İlk adım bir sezgidir ve bir patlama ile gelir, sonra zorluklar ortaya çıkar - bu şey pes eder ve o zaman "Böcekler" - bu kadar küçük hatalar ve zorluklar denir - kendilerini gösterir ve aylarca yoğun bir şekilde izlerler, çalışırlar. ticari başarı veya başarısızlığa kesinlikle ulaşılmadan önce ve emek gereklidir.

İlk mekanik langırt oyunu olan Baffle Ball , 1931'de "hatasız" olarak ilan edildi. II. Dünya Savaşı sırasında askeri teçhizatla ilgili problemler , bug (veya glitches ) olarak adlandırıldı. 1942'de yayınlanan bir kitapta Louise Dickinson Rich , elektrikli bir buz kesme makinesinden bahsederken , "Buz testeresi, yaratıcısı sevgilisinden böcekleri çıkarmak için getirilene kadar askıya alındı" dedi.

Isaac Asimov , 1944'te yayınlanan " Tavşanı Yakala " adlı kısa öyküsünde bir robotla ilgili sorunları anlatmak için "böcek" terimini kullandı .

Harvard Mark II elektromekanik bilgisayarının günlüğünden, cihazdan çıkarılan ölü bir güveyi gösteren bir sayfa .

"Hata" terimi, erken bir elektromekanik bilgisayardaki bir arızanın nedenini açıklayan bilgisayar öncüsü Grace Hopper tarafından bir hesapta kullanıldı. Hikayenin tipik bir versiyonu:

1946'da Hopper aktif görevinden serbest bırakıldığında, Harvard Fakültesi Hesaplama Laboratuvarı'na katıldı ve burada Mark II ve Mark III üzerinde çalışmaya devam etti . Operatörler, Mark II'deki bir hatayı, bir röleye hapsolmuş bir güveye kadar takip ederek bug terimini türettiler . Bu hata dikkatlice kaldırıldı ve kayıt defterine kaydedildi. İlk hatadan yola çıkarak bugün bir programdaki hataları veya aksaklıkları bug olarak adlandırıyoruz .

Hopper, hemen kabul ettiği gibi hatayı bulamadı. Kayıt defterindeki tarih 9 Eylül 1947 idi. Daha sonra Dahlgren, Virginia'daki Donanma Silahları Laboratuvarı'ndan William "Bill" Burke de dahil olmak üzere onu bulan operatörler mühendislik terimine aşinaydı ve böceği eğlenerek notasyonla tuttular. "İlk gerçek hata vakası bulundu." Hopper hikayeyi anlatmayı severdi. Ekli güve ile tamamlanan bu seyir defteri, Smithsonian Ulusal Amerikan Tarihi Müzesi koleksiyonunun bir parçasıdır .

İlgili " hata ayıklama " teriminin de bilgisayardaki kullanımından önce geldiği görülüyor: Oxford İngilizce Sözlüğü'nün kelimenin etimolojisi 1945'ten uçak motorları bağlamında bir tasdik içeriyor.

Yazılımın hatalar içerebileceği kavramı, Ada Lovelace'in Charles Babbage'ın analitik motoru için program "kartlarının " hatalı olma olasılığından bahsettiği analitik motor hakkındaki 1843 notlarına kadar uzanır:

... Analitik Motora gerekli işletimsel verileri sağlamak için aynı şekilde bir analiz süreci de gerçekleştirilmiş olmalıdır ; ve burada da olası bir hata kaynağı olabilir. Gerçek mekanizmanın süreçlerinde hatasız olduğu kabul edildiğinde, kartlar ona yanlış emirler verebilir.

"Sistemdeki Hatalar" raporu

New America adlı grup tarafından yönetilen Açık Teknoloji Enstitüsü, Ağustos 2016'da, ABD'li politika yapıcıların araştırmacıların yazılım hatalarını belirlemelerine ve çözmelerine yardımcı olmak için reformlar yapması gerektiğini belirten bir "Sistemdeki Hatalar" raporunu yayınladı. Rapor "yazılım güvenlik açığı keşfi ve ifşası alanında reform ihtiyacını vurgulamaktadır." Raporun yazarlarından biri, Kongre'nin daha büyük siber güvenlik sorunuyla mücadele etmek için bir dizi yasa tasarısını kabul etmesine rağmen, Kongre'nin siber yazılım güvenlik açığını ele almak için yeterince şey yapmadığını söyledi.

Devlet araştırmacıları, şirketler ve siber güvenlik uzmanları, genellikle yazılım kusurlarını keşfeden kişilerdir. Rapor, bilgisayar suçları ve telif hakkı yasalarında reform yapılması çağrısında bulunuyor.

Raporda, Bilgisayar Sahtekarlığı ve Kötüye Kullanımı Yasası, Dijital Binyıl Telif Hakkı Yasası ve Elektronik İletişim Gizliliği Yasası, güvenlik araştırmacılarının meşru güvenlik araştırmaları yürütürken rutin olarak giriştikleri eylemleri suç haline getiriyor ve para cezaları oluşturuyor.

terminoloji

Yazılım hatalarını tanımlamak için "hata" teriminin kullanımı yaygın olsa da, çoğu kişi bunun terk edilmesi gerektiğini önerdi. Bir argüman, "böcek" kelimesinin soruna bir insanın neden olduğu anlamından ayrıldığı ve bunun yerine kusurun kendi kendine ortaya çıktığını ima ettiği ve bunun yerine "böcek" terimini terk etmek gibi terimler lehine bir baskıya yol açtığıdır. sınırlı başarı ile "kusur". 1970'lerden beri Gary Kildall biraz mizahi bir şekilde "gaf" terimini kullanmayı önerdi.

Yazılım mühendisliğinde, hata metamorfizması (Yunanca meta = "değişim", morf = "biçim"), yazılım dağıtımının son aşamasında bir kusurun evrimini ifade eder. Yazılım geliştirme yaşam döngüsünün ilk aşamalarında bir analist tarafından yapılan ve döngünün son aşamasında bir "kusura" yol açan bir "hatanın" dönüştürülmesi, "hata metamorfizması" olarak adlandırılmıştır.

Tüm döngüdeki bir "hata"nın farklı aşamaları "hatalar", "anomaliler", "arızalar", "arızalar", "hatalar", "istisnalar", "çökmeler", "aksaklıklar", "hatalar" olarak tanımlanabilir. , "kusurlar", "olaylar" veya "yan etkiler".

önleme

Fransa'daki La Croix de Berny istasyonunda iki ekranda görüntülenen bir yazılım hatasından kaynaklanan hata .

Yazılım endüstrisi, hata sayılarını azaltmak için çok çaba sarf etti. Bunlar şunları içerir:

Tipografik hata

Hatalar genellikle programcı bir mantık hatası yaptığında ortaya çıkar . Programlama stilinde ve savunma amaçlı programlamada çeşitli yenilikler, bu hataların daha az olası veya daha kolay fark edilmesini sağlamak için tasarlanmıştır. Bazı yazım hataları, özellikle semboller veya mantıksal/ matematiksel operatörler , programın hatalı çalışmasına izin verirken, eksik sembol veya yanlış yazılmış ad gibi diğerleri programın çalışmasını engelleyebilir. Derlenmiş diller, kaynak kod derlendiğinde bazı yazım hatalarını ortaya çıkarabilir.

Geliştirme metodolojileri

Birkaç şema, daha az hata üretilmesi için programcı etkinliğinin yönetilmesine yardımcı olur. Yazılım mühendisliği (yazılım tasarımı konularını da ele alır), kusurları önlemek için birçok teknik uygular. Örneğin, resmi program spesifikasyonları , tasarım hatalarının ortadan kaldırılabilmesi için programların tam davranışını belirtir. Ne yazık ki, biçimsel özellikler, birleşimsel patlama ve belirsizlik sorunları nedeniyle en kısa programlardan başka hiçbir şey için pratik değildir .

Birim testi , bir programın gerçekleştireceği her işlev (birim) için bir test yazmayı içerir.

Test odaklı geliştirmede birim testleri koddan önce yazılır ve tüm testler başarıyla tamamlanana kadar kod tamamlanmış sayılmaz.

Çevik yazılım geliştirme , nispeten küçük değişikliklerle sık sık yazılım sürümlerini içerir. Kusurlar, kullanıcı geri bildirimi ile ortaya çıkar.

Açık kaynak geliştirme, herkesin kaynak kodunu incelemesine olanak tanır. Eric S. Raymond tarafından Linus yasası olarak popüler hale getirilen bir düşünce okulu, popüler açık kaynaklı yazılımların diğer yazılımlardan daha az hataya sahip olma veya hiç hata yapma şansının daha fazla olduğunu söylüyor çünkü "yeterli göz küresi verildiğinde, tüm böcekler sığdır". Ancak bu iddia tartışmalıdır: bilgisayar güvenliği uzmanı Elias Levy , "karmaşık, az anlaşılan ve belgelenmemiş kaynak koddaki güvenlik açıklarını gizlemek kolaydır" diye yazdı, çünkü "insanlar kodu gözden geçirseler bile, bu onların onların olduğu anlamına gelmez. Bunu yapmak için nitelikli." Bunun gerçekten tesadüfen gerçekleşmesine bir örnek, Debian'daki 2008 OpenSSL güvenlik açığıydı .

Programlama dili desteği

Programlama dilleri , statik tip sistemler , kısıtlı ad alanları ve modüler programlama gibi hataları önlemeye yardımcı olacak özellikler içerir . Örneğin, bir programcı (sözde kod) yazdığında LET REAL_VALUE PI = "THREE AND A BIT", bu sözdizimsel olarak doğru olsa da, kod bir tür denetiminde başarısız olur . Derlenmiş diller, programı çalıştırmadan bunu yakalar. Yorumlanan diller, çalışma zamanında bu tür hataları yakalar. Bazı diller, daha yavaş performans pahasına, kolayca hatalara yol açan özellikleri kasıtlı olarak hariç tutar: genel ilke şudur ki, özellikle bakım maliyetinin önemli olduğu göz önüne alındığında, biraz daha hızlı çalışan esrarengiz koddan daha basit, daha yavaş kod yazmak neredeyse her zaman daha iyidir. . Örneğin, Java programlama dili işaretçi aritmetiğini desteklemez ; Pascal ve komut dosyası dilleri gibi bazı dillerin uygulamaları , en azından bir hata ayıklama yapısında, genellikle dizilerin çalışma zamanı sınırlarının denetimine sahiptir.

kod analizi

Kod analizi araçları , program metnini derleyicinin yeteneklerinin ötesinde inceleyerek olası sorunları tespit etmede geliştiricilere yardımcı olur. Genel olarak, bir belirtim verilen tüm programlama hatalarını bulma sorunu çözülebilir olmasa da (bkz. durma sorunu ), bu araçlar, insan programcıların genellikle yazılım yazarken belirli türde basit hatalar yapma eğiliminde olduğu gerçeğinden yararlanır.

Enstrümantasyon

Yazılımın çalışırken performansını izlemek için, özellikle darboğazlar gibi sorunları bulmak veya doğru çalışma konusunda güvence vermek için araçlar, koda açıkça gömülebilir (belki de bir ifade kadar basit PRINT "I AM HERE") veya şu şekilde sağlanabilir: araçlar. Bir kod parçasının çoğu zaman nerede olduğunu bulmak genellikle şaşırtıcıdır ve bu varsayımların kaldırılması kodun yeniden yazılmasına neden olabilir.

Test yapmak

Yazılım testçileri , birincil görevi hataları bulmak veya testi desteklemek için kod yazmak olan kişilerdir. Bazı projelerde, programın geliştirilmesinden daha fazla kaynak test etmek için harcanabilir.

Test sırasındaki ölçümler, kalan olası hataların sayısı hakkında bir tahmin sağlayabilir; bu, bir ürün ne kadar uzun süre test edilir ve geliştirilirse o kadar güvenilir hale gelir.

hata ayıklama

Tipik hata geçmişi ( GNU Classpath proje verileri). Kullanıcı tarafından gönderilen yeni bir hata onaylanmadı. Bir geliştirici tarafından yeniden üretildiğinde, onaylanmış bir hatadır. Onaylanan hatalar daha sonra düzeltilir . Diğer kategorilere ait hatalar (tekrarlanamaz, düzeltilmeyecek vb.) genellikle azınlıktadır.
Ana madde: Hata ayıklama

Hataları bulmak ve düzeltmek veya hata ayıklamak , bilgisayar programlamanın önemli bir parçasıdır . Erken bir bilgisayar öncüsü olan Maurice Wilkes , 1940'ların sonlarında, hayatının geri kalanının kendi programlarında hatalar bulmakla geçirileceğini fark ettiğini açıkladı.

Genellikle, hata ayıklamanın en zor kısmı hatayı bulmaktır. Bir kez bulunduğunda, düzeltmek genellikle nispeten kolaydır. Hata ayıklayıcılar olarak bilinen programlar, program davranışını gözlemlemek için satır satır kod yürüterek, değişken değerleri ve diğer özellikleri izleyerek programcıların hataları bulmasına yardımcı olur. Hata ayıklayıcı olmadan, program yürütmesini izlemek veya değerleri göstermek için mesajların veya değerlerin bir konsola veya bir pencereye veya günlük dosyasına yazılabilmesi için kod eklenebilir.

Bununla birlikte, bir hata ayıklayıcının yardımıyla bile, hataları bulmak bir sanattır. Bir programın bir bölümündeki bir hatanın tamamen farklı bir bölümde hatalara neden olması ve bu nedenle izlemeyi özellikle zorlaştırması (örneğin, bir dosya G/Ç rutininin başarısız olmasına neden olan bir grafik oluşturma rutinindeki bir hata) nadir değildir. , sistemin görünüşte ilgisiz bir bölümünde.

Bazen bir hata, izole bir kusur değildir, ancak programcının bir düşünme veya planlama hatasını temsil eder. Bu tür mantık hataları , programın bir bölümünün elden geçirilmesini veya yeniden yazılmasını gerektirir. Kod incelemesinin bir parçası olarak, kodda adım adım ilerlemek ve yürütme sürecini hayal etmek veya yazıya dökmek, genellikle hatayı bu şekilde yeniden üretmeden hatalar bulabilir.

Daha tipik olarak, bir hatayı bulmanın ilk adımı onu güvenilir bir şekilde yeniden oluşturmaktır. Hata yeniden üretilebilir olduğunda, programcı, programın yanlış gittiği noktayı bulmak için hatayı yeniden üretirken bir hata ayıklayıcı veya başka bir araç kullanabilir.

Bazı hatalar, programcının yeniden oluşturması zor olabilecek girdilerle ortaya çıkar. Therac-25 radyasyon makinesi ölümlerinin bir nedeni , yalnızca makine operatörü bir tedavi planına çok hızlı bir şekilde girdiğinde ortaya çıkan bir hataydı (özellikle bir yarış durumu ); Bunu yapabilmek günlerce pratik gerektirdi, bu nedenle hata testte veya üretici onu kopyalamaya çalıştığında ortaya çıkmadı. Programı bir hata ayıklayıcıyla çalıştırmak gibi, hatayı bulmaya yardımcı olmak için kurulum artırıldığında diğer hatalar ortaya çıkmayabilir; bunlara heisenbugs denir (heisenberg belirsizlik ilkesinden sonra mizahi bir şekilde adlandırılır ).

1990'lardan bu yana, özellikle Ariane 5 Flight 501 felaketinin ardından , soyut yorumlamayla statik kod analizi gibi hata ayıklamaya yönelik otomatik yardımlara ilgi arttı .

Bazı hata sınıflarının kodla hiçbir ilgisi yoktur. Hatalı dokümantasyon veya donanım, kod dokümantasyonla eşleşmesine rağmen sistem kullanımında sorunlara yol açabilir. Bazı durumlarda, kod artık belgelerle eşleşmese bile kodda yapılan değişiklikler sorunu ortadan kaldırır. Bir ROM'un yeni bir sürümünü yapmak , özellikle ticari ürünlerse, donanımı yeniden üretmekten çok daha ucuz olduğundan, gömülü sistemler sıklıkla donanım hatalarını giderir .

Hata karşılaştırması

Test etme ve hata ayıklama konusunda tekrarlanabilir araştırmaları kolaylaştırmak için araştırmacılar, küratörlü hata karşılaştırma ölçütlerini kullanır:

  • Siemens kıyaslaması
  • ManyBugs, dokuz açık kaynaklı programda 185 C hatalarının bir ölçütüdür.
  • Defects4J, 5 açık kaynaklı projeden 341 Java hatasının bir karşılaştırmasıdır. Çeşitli yama türlerini kapsayan ilgili yamaları içerir.
  • BEARS, test hatalarına odaklanan sürekli entegrasyon derleme hatalarının bir ölçütüdür. Travis CI üzerindeki açık kaynaklı projelerden derlemeler izlenerek oluşturulmuştur .

Hata yönetimi

Hata yönetimi, düzeltilmiş kodu belgeleme, kategorilere ayırma, atama, çoğaltma, düzeltme ve serbest bırakma sürecini içerir. Yazılımda önerilen değişiklikler (hataların yanı sıra geliştirme istekleri ve hatta tüm sürümler) genellikle hata izleme sistemleri veya sorun izleme sistemleri kullanılarak izlenir ve yönetilir . Eklenen öğelere kusurlar, biletler, sorunlar veya çevik geliştirme paradigmasının ardından hikayeler ve destanlar denebilir. Kategoriler nesnel, öznel veya sürüm numarası , yazılımın alanı, önem derecesi ve önceliği gibi bir kombinasyon olabilir ve ayrıca özellik isteği veya hata gibi sorunun türü de olabilir.

Bir hata triyajı, hataları inceler ve bunların düzeltilip düzeltilmeyeceğine ve ne zaman düzeltileceğine karar verir. Karar, hatanın önceliğine ve proje programları gibi faktörlere dayalıdır. Triyaj, hataların nedenini araştırmak değil, onları düzeltmenin maliyetini araştırmak içindir. Triyaj düzenli olarak gerçekleşir ve önceki toplantıdan bu yana açılan veya yeniden açılan hatalardan geçer. Önceliklendirme sürecinin katılımcıları genellikle proje yöneticisi, geliştirme yöneticisi, test yöneticisi, yapı yöneticisi ve teknik uzmanlardır.

önem

Önem derecesi , hatanın sistem çalışması üzerindeki etkisinin yoğunluğudur. Bu etki, veri kaybı, finansal, iyi niyet kaybı ve boşa harcanan çaba olabilir. Şiddet seviyeleri standart değildir. Etkiler sektöre göre farklılık gösterir. Bir video oyunundaki bir çökmenin, bir web tarayıcısındaki veya gerçek zamanlı izleme sistemindeki bir çökmeden tamamen farklı bir etkisi vardır. Örneğin, hata önem düzeyleri "çökme veya takılma", "geçici çözüm yok" (müşterinin belirli bir görevi başarmasının hiçbir yolu olmadığı anlamına gelir), "geçici çözümü var" (kullanıcının görevi yine de başarabileceği anlamına gelir), "görsel olabilir. kusur" (örneğin, eksik bir görüntü veya yerinden çıkmış düğme veya form öğesi) veya "belge hatası". Bazı yazılım yayıncıları "kritik", "yüksek", "düşük", "engelleyici" veya "önemsiz" gibi daha nitelikli önem dereceleri kullanır. Bir hatanın ciddiyeti, düzeltme önceliğine göre ayrı bir kategori olabilir ve ikisi ayrı ayrı ölçülebilir ve yönetilebilir.

Öncelik

Bir hatanın planlanan değişiklikler listesine düştüğü öncelik kontrolleri. Öncelik, her yazılım üreticisi tarafından belirlenir. Öncelikler 1'den 5'e kadar sayısal olabilir veya "kritik", "yüksek", "düşük" veya "ertelenmiş" gibi adlandırılmış olabilir. Bu derecelendirme ölçekleri, önem derecesi derecelendirmelerine benzer veya hatta aynı olabilir , ancak hatanın önem derecesi ile tahmini düzeltme çabasının bir kombinasyonu olarak değerlendirilir; Önem düzeyi düşük ancak düzeltilmesi kolay bir hata, düzeltilmesi aşırı çaba gerektiren orta düzeyde önemdeki bir hatadan daha yüksek önceliğe sahip olabilir. Öncelik derecelendirmeleri, bir sonraki yazılım sürümünden önce düzeltilmesi gereken tüm hataları belirten "kritik" öncelik gibi ürün sürümleriyle uyumlu hale getirilebilir.

Yazılım sürümleri

Bilinen, düşük öncelikli hatalara sahip yazılımları yayınlamak yaygın bir uygulamadır. Yeterince yüksek önceliğe sahip hatalar, yalnızca bu düzeltmelere sahip modülleri içeren kodun bir bölümünün özel olarak yayınlanmasını garanti edebilir. Bunlar yamalar olarak bilinir . Çoğu sürüm, davranış değişiklikleri ve çoklu hata düzeltmelerinin bir karışımını içerir. Hata düzeltmelerini vurgulayan sürümler, özellik eklemelerini veya değişikliklerini vurgulayan ana sürümlerden ayırt etmek için bakım sürümleri olarak bilinir.

Bir yazılım yayıncısının belirli bir hatayı düzeltmemeyi ve hatta düzeltmemeyi seçmesinin nedenleri arasında şunlar yer alır:

  • Bir son teslim tarihine uyulmalıdır ve tüm hataları son tarihe kadar düzeltmek için kaynaklar yetersizdir.
  • Hata, yaklaşan bir sürümde zaten düzeltildi ve yüksek önceliğe sahip değil.
  • Hatayı düzeltmek için gereken değişiklikler çok maliyetlidir veya çok sayıda diğer bileşeni etkileyerek büyük bir test faaliyeti gerektirir.
  • Bazı kullanıcıların mevcut buggy davranışına güvendiğinden şüphelenilebilir veya bilinebilir; önerilen bir düzeltme, bir kesinti değişikliğine neden olabilir .
  • Sorun, yaklaşmakta olan bir sürümle geçerliliğini yitirecek bir alanda; sabitlemek gereksizdir.
  • "Bu bir hata değil, bir özelliktir". Beklenen ve algılanan davranış veya belgelenmemiş özellik arasında bir yanlış anlama ortaya çıktı .

Türler

Yazılım geliştirme projelerinde herhangi bir aşamada bir "hata" veya "hata" ortaya çıkabilir. Hatalar, spesifikasyon, tasarım, kodlama, veri girişi veya dokümantasyon sırasında bir yazılım ekibi tarafından yapılan gözden kaçma veya yanlış anlamalardan kaynaklanır. Örneğin, bir kelime listesini alfabetik hale getirmek için nispeten basit bir program, tasarım bir kelime bir tire içerdiğinde ne olması gerektiğini düşünmede başarısız olabilir . Veya soyut bir tasarımı koda dönüştürürken, kodlayıcı istemeden birer birer bir hata oluşturabilir ve bir listedeki son kelimeyi sıralayamayabilir. Hatalar bir yazım hatası kadar basit olabilir: ">" istendiğinde bir "<".

Diğer bir hata kategorisi, programların aynı anda çalışan birden fazla bileşeni olduğunda ortaya çıkabilecek bir yarış durumu olarak adlandırılır. Bileşenler, geliştiricinin amaçladığından farklı bir sırayla etkileşime girerse, birbirleriyle etkileşime girebilir ve programın görevlerini tamamlamasını durdurabilir. Bir programın her yürütülmesi sırasında ortaya çıkmayabileceğinden, bu hataları tespit etmek veya tahmin etmek zor olabilir.

Kavramsal hatalar, bir geliştiricinin yazılımın yapması gerekenleri yanlış anlamasıdır. Ortaya çıkan yazılım, geliştiricinin anlayışına göre çalışabilir, ancak gerçekten ihtiyaç duyulanı değil. Diğer çeşitler:

Aritmetik

Mantık

Sözdizimi

  • Eşitlik testi yerine atama yapmak gibi yanlış operatörün kullanılması . Örneğin, bazı dillerde x=5, x'in değerini 5'e ayarlarken, x==5, x'in halihazırda 5 mi yoksa başka bir sayı mı olduğunu kontrol eder. Yorumlanan diller, bu tür kodun başarısız olmasına izin verir. Derlenmiş diller, test başlamadan önce bu tür hataları yakalayabilir.

Kaynak

Çoklu iş parçacığı

arayüz

  • Yanlış API kullanımı.
  • Yanlış protokol uygulaması.
  • Yanlış donanım kullanımı.
  • Belirli bir platformun yanlış varsayımları.
  • Uyumsuz sistemler. İki sistem farklı sürümler kullandığında yeni bir API veya iletişim protokolü çalışıyor gibi görünebilir, ancak bir sürümde uygulanan bir işlev veya özellik değiştirildiğinde veya diğerinde eksik olduğunda hatalar oluşabilir. Sürekli çalışması gereken üretim sistemlerinde, telekomünikasyon endüstrisi veya internet gibi büyük bir güncelleme için tüm sistemin kapatılması mümkün olmayabilir. Bu durumda, büyük bir ağın kesintiye uğramasını en aza indirmek için büyük bir sistemin daha küçük segmentleri ayrı ayrı yükseltilir. Ancak bazı bölümler gözden kaçabilir ve yükseltilemeyebilir ve bulması ve onarılması zor olabilecek uyumluluk hatalarına neden olabilir.
  • Yanlış kod açıklamaları

Takım çalışması

  • Yayılmamış güncellemeler; örneğin programcı "myAdd" öğesini değiştirir ancak aynı algoritmayı kullanan "mySubtract"ı değiştirmeyi unutur. Bu hatalar, Kendini Tekrar Etme felsefesi tarafından azaltılır.
  • Güncel olmayan veya yanlış yorumlar: birçok programcı, yorumların kodu doğru bir şekilde tanımladığını varsayar.
  • Belgeler ve ürün arasındaki farklar.

etkileri

Bir yazılım hatasının neden olabileceği hasarın miktarı ve türü, yazılım kalitesine ilişkin karar vermeyi, süreçleri ve politikayı doğal olarak etkiler. İnsanlı uzay uçuşu veya otomotiv güvenliği gibi uygulamalarda , yazılım kusurları insan yaralanmasına ve hatta ölüme neden olma potansiyeline sahip olduğundan, bu tür yazılımlar, örneğin bir çevrimiçi alışveriş web sitesine göre çok daha fazla inceleme ve kalite kontrolüne sahip olacaktır. Yazılım kusurlarının bir bankaya veya müşterilerine ciddi mali zarar verme potansiyeline sahip olduğu bankacılık gibi uygulamalarda, kalite kontrol de örneğin bir fotoğraf düzenleme uygulamasından daha önemlidir. NASA'nın Yazılım Güvencesi Teknoloji Merkezi , hata sayısını 1000 kod satırı ( SLOC ) başına 0,1'in altına düşürmeyi başardı, ancak bu iş dünyasındaki projeler için uygun görülmedi.

" Uçuş Yazılım Karmaşıklığı " üzerine bir NASA araştırmasına göre , "olağanüstü iyi bir yazılım geliştirme süreci, kusurları 10.000 kod satırı başına 1 kusura kadar düşürebilir."

Hataların neden olduğu hasar dışında, maliyetlerinin bir kısmı onları düzeltmek için harcanan çabadan kaynaklanmaktadır. 1978'de Lientz ve ark. projelerin medyanının, geliştirme çabasının yüzde 17'sini hata düzeltmeye yatırdığını gösterdi. 2020'de GitHub depolarında yapılan araştırmalarda medyanın %20 olduğunu gösterdi.

Bilinen hatalar

Ana madde: Yazılım hatalarının listesi

Bir dizi yazılım hatası, genellikle ciddiyetleri nedeniyle iyi bilinir: örnekler arasında çeşitli uzay ve askeri uçak kazaları sayılabilir. Muhtemelen en ünlü bug 2000 yılı problemi olarak da bilinen ve 2000 yılının başında bilgisayarların 1900 olduğunu düşünmesi sonucu dünya çapında ekonomik çöküşün olacağından korkulan Y2K bug'ıdır. , büyük bir sorun yaşanmadı.) 2012 hisse senedi alım satım kesintisi , eski API ile yeni bir API arasında böyle bir uyumsuzluk içeriyordu.

popüler kültürde

  • Hem 1968 romanı 2001: A Space Odyssey hem de ilgili 1968 filmi 2001: A Space Odyssey , bir uzay gemisinin yerleşik bilgisayarı HAL 9000 , tüm mürettebat üyelerini öldürmeye çalışır. Devam eden 1982 romanı 2010: Odyssey Two ve beraberindeki 1984 filmi, 2010'da , bu eylemin bilgisayarın birbiriyle çelişen iki amaçla programlanmasından kaynaklandığı ortaya çıkıyor: tüm bilgilerini tam olarak ifşa etmek ve mürettebattan uçuş sırrının gerçek amacı; bu çatışma HAL'ın paranoyaklaşmasına ve sonunda cinayete meyilli olmasına neden oldu.
  • Nena 1983 şarkısının İngilizce versiyonunda 99 Luftballons (99 Red Balloons) "yazılımdaki hatalar"ın bir sonucu olarak, 99 kırmızı balondan oluşan bir grubun serbest bırakılması, eşdeğer bir fırlatma tepkisi gerektiren bir düşman nükleer füze fırlatma ile karıştırılıyor. , felaketle sonuçlanır.
  • 1999 Amerikan komedisi Office Space'de , üç çalışan, şirketin bilgisayar sistemine, ayrı bir banka hesabına yuvarlanmış peniler gönderen bir virüs bulaştırarak, Y2K bilgisayar hatasını düzeltmekle olan meşguliyetlerinden yararlanmaya çalışır. Virüsün kendi hesabına erken büyük miktarda para gönderen kendi hatası olduğu için plan geri teper.
  • Ellen Ullman'ın 2004 tarihli romanı The Bug , bir programcının bir veritabanı uygulamasında bulunması zor bir hatayı bulma girişimi hakkındadır.
  • 2008 Kanada filmi Control Alt Delete , 1999'un sonunda şirketindeki 2000 yılı sorunuyla ilgili hataları düzeltmeye çalışan bir bilgisayar programcısı hakkındadır.

Ayrıca bakınız

Referanslar

Dış bağlantılar