.:: Tekamül ::.

FELAKET NEDENİ: Yazılım Hatası. Kulağa önemsiz gibi gelen şeyler bazen korkunç sonuçlar doğurabiliyor. Düşen uçaklar, patlayan roketler, yıkılan köprüler, tam sürat sürüş esnasında açılıveren hava yastıkları, ölümcül dozda radyoterapiye maruz kalan hastalar, gelişkin silahlarıyla istemeden birbirlerini vuran askerler, daha neler neler...Hatalı bilgisayar programlarının sebebiyet verdiği felaketlerin listesi uzadıkça uzuyor. Ama PC'yle her gün çalışan ve uygulama yazılımlarının ne kadar sık çöküp durduğunu acı deneyimleri doğrultusunda bilenler, bu kadar az felaketin gerçekleşmiş olmasına şükrediyorlar. Teknolojinin insan yaşamına mal olan akıllara durgunluk verici başarısızlığına, birde ekonomide yazılımların neden olduğu dev maddi zararlar, başarısız iletişim ve taşıma ağlarının insanı öfkelendirmesi ekleniyor. Başarısızlığa uğramış büyük projeler ayrıca bir hayli büyük imaj sarsıntısına yol açıyor.

Teknolojinin gelişimine dair pembe hayalleri olanlara karşı çıkan uzmanlar, her şeyin daha da kötüye gideceği kehanetinde bulunuyorlar. Berlin'deki Fraunhofer Enstitüsü Bilgisayar Mimarisi ve Yazılım Teknolojisi bölümünden (FIRST) Dr. Sergio Montenegro bunun için basit bir hesap yapıyor. Bilişim uzmanına göre, iyi yazılmış bir programda her 1.000 satır başına beş hata bulunuyor. Eğer önümüzdeki iki yıl içinde daha iyi test prosedürleriyle bu rakam binde dört seviyesine indirgenirse, bu %20'lik bir gelişmeye tekabül edecek. Ne var ki, tahminlere göre aynı süre içinde ortalama program uzunluğu on kat artacak. Bu sebeple Montenegro önümüzdeki iki yıl içinde programlama hatalarının sekize katlanışına şahit olacağımızı söylüyor. Günümüzde bir cep telefonu yazılımı bile 200.000 satır kod içeriyor. Windows'un kodu ise 45 milyon satıra ulaşmış durumda. Windows XP'nin program kodu yazdırıldığmda yaklaşık 68 metre yüksekliğinde bir kağıt istifi oluşuyor.

Münihli bilişim profesörü Thomas Huckle da birçok hatanın nedeninin programın büyüklüğü olduğu fikrinde. "Sırf program kodunun miktarından yola çıkarsak bile hataların sayısı program başına binleri buluyor." Bu hem yazılım paketleri, hem de donanım ürünlerine tümleşik yazılımlar için geçerli. Elbette daha iyi hata oranları da mevcut. Örneğin uzay mekiği projesinin yazılımı 1.000 satır başına 0,1 hata düştüğü için özellikle güvenli sayılıyor. Ancak yaklaşık 3 milyon satır kod içeren yazılımda hala 300 hata keşfedilmemiş durumda varlığını devam ettiriyor. "İnsanlar hata yapıyor ve bugünkü yazılım konseptlerinde bu hatalar birikiyor. Bunun önüne geçilmesi mümkün değil," diyor sayısız bug'ın başlıca sebeplerini bilen Prof. Huckle. Bunların birçoğu, şayet programcılar programlarına özenli güvenlik sorguları dahil ederlerse önlenebilir. Sözgelimi sıfıra bölmeler, uzun sayılardan kaynaklanan bellek taşmaları ya da yanlış dönüştürülmüş değerler. Ara sıra küçük yuvarlama hataları toplamda korkunç hatalara yol açabiliyor; özellikle de değerler sürekli değişiyor ve tampon bellekte depolanıyorsa. Her seferinde üstün körü iş görmek ve küçük yazım hataları programları birer saatli bombaya çeviriyor: Eksik virgüller, noktalı virgül yerine iki nokta üst üste ve daha niceleri. "Bu tür hataların çoğunluğu hiç su yüzüne çıkmaz, ancak bir tanesi bile bir uyduyu yere çakmak için yeterli," diyor Huckle.

Program Kodları Arttıkça Hatalarda Artıyor

Programcıların bireysel hataları bir yana, bir dizi başka çöküş nedeni daha var. Çoğu zaman, mevcut yazılımlar yeni amaçlar için, gerekli değişiklikler yapılmadan kullanılıyor. Beklenmedik bir olay meydana gelirse program çöküyor. Arianne 5 roketi bu sebepten 1995 yılında düştü. Donanım ve yazılım birbirine uymuyorsa da kötü bir şeyler olması yakın demek. Aynı şey işletim sisteminin yeni bir sürümü üzerinde kullanılan eski programlar için de geçerli. Büyük yazılım projelerinin yönetimi giderek zorlaşıyor. Farklı parçalar üzerinde aynı anda birden çok programcı grubu çalışıyor ve sonuçta bu parçalar bir araya getiriliyor. Huckle, birçoğu yıllar alan bu projelerin tatminkar olmayan sonuçlarını "Arabirim hataları önceden programlanmış," şeklinde yorumluyor. Çoğu kez beklenen giriş ve çıkışlar birbirine uymuyor bile.

"Yazılım geliştiricileri test etmeye ayırdıkları zamanı giderek azaltıyorlar" suçlamasında bulunuyor yazılım endüstrisini yakından takip eden profesör. Güvenlik bakımından kritik alanlarda hata bilinci daha da gelişiyor ancak yeni yazılımlar kullanıcıya teslim edilmeden önce çok az test ediliyor. Huckle, otomatik test araçlarının sayısının azlığından yakınıyor. "Başlıca hata kaynakları ve hassas noktalar iyi biliniyor, bu konuda bir şeyler yapılabilir." Kontrolden tasarruf edilmesinin nedenlerinden biri, geçtiğimiz yıllarda artan zaman ve maliyet baskısı. Zaman alıcı işlerin yükünü yazılım geliştiricilerin sırtından alan ve dikkatsizlikten kaynaklanan hatalara düşmeyen programlama makineleri işe yarayabilir.

Hedef: Ucuz ve hata toleranslı yazılım

Daha ucuza ve aynı zamanda daha az hatayla yazılım geliştirmek, Kaiserslautern'deki Fraunhofer Enstitüsü Deneysel Yazılım Mühendisliği bölümünün (IESE) Marmot projesiyle ulaşmayı hedeflediği bir amaç. Araştırmacılar, elektrikli aygıtlar ya da makineler gibi tümleşik sistemler için yazılım geliştirme modellerini sembolleri kullanabilen bir Lego robo-tuyla tanıtıyorlar. Marmot halihazırda başka uygulamaların içinde çalışır durumda olan program yapıtaşlarından oluşuyor.

Çökmeyen bir sistem mümkün mü?

IESE, bu konsepti kendinden emin bir şekilde "çöküşe karşı güvenli" olarak nitelerken, başka bir yerde yazılımların asla tümüyle hatasız olamayacağı görüşünden sonuçlar çıkarılıyor. Kaliforniya'daki Stanford Üniversitesi'nin araştırmacıları "çöküş yönelimli programları gündeme getiriyor. Burada da yazılım değişik ve birbirinden ayrı bileşenlerden bir araya geliyor. Tüm sistem, tek bir program bölümü çökerse ve yeniden başlatılmak zorunda kalınırsa da çalışmayı sürdürmek üzere bir araya getirilmiş.

Berlin'deki FIRST'te Dr. Sergio Montenegro benzeri bir yol izliyor. Fraunhofer araştırmacısı da aynı şekilde, hata durumunda bile çalışmayı sürdürecek programlar üzerinde çalışıyor. Geliştirme hatalarının ve çöküşlerin ana nedeni olarak sistemlerin karmaşıklığı belirlenmiş. Program kodlarının kontrolden çıkarcasına arttığı bu dönemde, onun olabildiğince basit bir işletim sistemi arayışı demode bir görüş gibi görülebilir. "Artık hiç kimse bir sistemde nelerin olup bittiğini bilemiyor," diyerek günümüzdeki yazılım geliştirme konseptini eleştiriyor bilim adamı. "Bir şeyi her zaman basit ya da karmaşık yapmak imkanı vardır. Ne yazık ki bugünkü eğilim karmaşık yapmaktan yana, çünkü böylesi daha modern görünüyor."

Montenegro'nun felsefesine göre, bir programdaki her bir işlev için en basitinden bir karmaşıklık bulunabilir. Şurası açık ki, Montenegro bunu birçok durumda bulmuş. FIRST'te geliştirilmiş gerçek zamanlı işletim sistemi BOSS, sadece 3.500 satırlık bir kodla yetiniyor ve ileride daha da küçültülecek. "Aynı işlevsellikte en basit hale gelene kadar," diye heyecanla anlatıyor bilim adamı. İşletim sistemi her amaca hizmet edebilecek: "Basit şeyler her maksatla kullanılabilir, her zaman uyumludurlar." İlk kullanım alanları yerleşik sistemler, uydu yönetimi, elektronik loto ve medikal teknoloji.

Basit yapı dağıtık hata toleranslı sistemlerin inşasını kolaylaştırıyor. "Güvenli bir sistemde şu ilke geçerli: Hiçbir şey bir başkasına bağımlı olamaz," diye açıklıyor Montenegro bu stratejiyi. Bir çöküş durumunda önemli olan şey başlangıç noktasına olabildiğince çabuk dönmek. Bunun için gereken prosedür bir hayli çetrefilli, çünkü çöküş anında önceden belirlenmiş bir koşul bulunmuyor. Bu yüzden, BOSS bir program çöktüğü anda külfetli bir güvenlik arayışına girişmiyor, ilgili süreci yeni baştan başlatıyor. Tüm program bölümleri her yerde ve her zaman kesintiye uğratılabilecek şekilde programlanmış. Bunun için her bir bileşen öteki süreçlerle senkronize olmasını sağlayacak, her bir veri aktarımında gönderilen bir asgari dahili duruma sahip. "Yeni başlatılmış bir süreç varsa, sistem ona 'Hey çocuklar, neler oluyor?' diye soruyor ve tekrar çalışmaya hazır hale geliyor," diye betimliyor Montenegro bu prosedürü. Daha karmaşık sistemlerin kontrolü çok ama çok daha zor oluyor.

Yedekli yazılım mimarisi

Fazlalıklarından arındırılmış olan işletim sistemi, redundant yapıların yönetimini ve inşasını da kolaylaştırıyor. Mimari bunun için değişik olanaklar sunuyor. Birden fazla paralel çalışan işletim sisteminin entegrasyonu ve aynı şekilde birden fazla denetçinin kullanılması mümkün. Bunların sonuçları bir ya da birden fazla jüri tarafından değerlendiriyor. Bunlar, sapan sonuçları teşhis ediyor ve çoğunluk kararıyla en olası değeri ortaya çıkarıyorlar. "Tek başına yedekli sistem için yalnızca yük olur ve yardımı dokunmazdı," diye vurguluyor Montenegro. Yönetim işlevleri, güvenilmez bileşenlere rağmen güvenilir bir çalışma ortamı sağlıyor.

Teksash firma Ciaro Netvvorks'ün teknik yöneticisi donanım uzmanı Steven VVallach da bugünkü yazılım konseptlerini bariz biçimde eleştiriyor. Donanımın geliştirilmesi, elektronlar ve fotonlar gibi temel parçacıkların davranışına dayanan fiziksel yasaları ve denklemleri göz önünde bulundururken, yazılımlar hala 20 yıl öncesinde olduğu gibi programlanıyor. VVallach "Softron" adını verdiği en küçük yazılım birimini arıyor. Yazılımın bu temel parçacıklarıyla bilgisayarlar matematiksel formüller kullanarak çözümleri hesaplayabilecek. VVallach'ın tasarımları uzmanlar dünyasında tartışmalı, ancak uzmanlar bir noktada hemfikir: Gelecek için tümüyle yeni bir yazılım anlayışına ihtiyacımız var.