1996 yılında, Avrupa Uzay Ajansı’nın büyük umutlarla geliştirdiği Ariane 5 roketi, fırlatıldıktan yalnızca 37 saniye sonra parçalanarak yerle bir oldu. Bu felaket, sadece maddi değil, aynı zamanda yazılım mühendisliği tarihine kazınan en çarpıcı derslerden biri haline geldi.





Ne Oldu?

Ariane 5 roketinde, daha önce Ariane 4’te kullanılan bir yazılım modülü tekrar kullanıldı. Ancak Ariane 5’in kalkış sırasında yatay hızı çok daha fazlaydı. Bu hız, sistemin “BH” (yatay sapma) adı verilen bir değişkeni hesaplamasına ve bu değerin çok büyük çıkmasına neden oldu.


Bu büyük değer, 64 bit kayan nokta formatından 16 bit işaretli tam sayıya dönüştürülmek istendiğinde taşma (overflow) oluştu. Ancak yazılım bu dönüşüm için yeterli hata kontrolü (exception handling) içermiyordu. Çünkü geliştiriciler sadece bazı değişkenler için sınır kontrolleri koymuşlardı — bu değişken için koymamışlardı. Çünkü Ariane 4’te böyle bir problem olmuyordu.

Sonuçta sistem bir hata (exception) fırlattı ve bu hata hem birincil hem de yedek atalet ölçüm sistemlerini (IRS) durdurdu. IRS durunca, roketin yönlendirme sistemi bozuldu. Bilgisayar, hatalı verileri gerçek sanarak roketin motorlarını yanlış yönlere çevirdi. Bu da roketin kontrolden çıkmasına ve otomatik imha sisteminin devreye girerek fırlatmanın başarısız olmasına yol açtı.



Ada Programlama Dili ve Yanlış Suçlama

Ariane 5'in yazılımı Ada diliyle yazılmıştı. Ada, ABD Savunma Bakanlığı tarafından güvenlik-kritik sistemler için geliştirilmiş, tip güvenliği yüksek, statik analizleri destekleyen bir dildir.



Ancak burada sorun Ada’nın kendisi değil, geliştirilen yazılımın test edilmeden yeniden kullanılması ve hata durumlarına karşı koruyucu mantığın eklenmemiş olmasıydı. “Bu değer asla bu kadar yüksek olmayacak” şeklinde varsayılan bir durum felaketle sonuçlandı.



Kurtarılan Parça: Uydu Taşıyıcı Destek Ayakları

Roketten geriye kalan az sayıdaki parçadan biri, şu anda Avrupa Uzay Ajansı tarafından sergilenmektedir. Bu metalik yapısal destek parça, kazanın fiziksel şiddetini ortaya koymakla birlikte, yazılım testinin önemini simgesel olarak taşır hale geldi.







Yazılım Test Mühendisliğine Vurgu

Ariane 5 olaydır ki, yazılım test mühendisliğinin salt kodu test etmek değil, bağlamı (context) ve donanım-yazılım etkileşimini test etmek olduğunu gözler önüne serdi. Kodun birden fazla platformda tekrar kullanılması, sadece syntax doğruluğu ile değil, çalışacağı fiziksel sistemin koşullarına göre de test edilmelidir.


Bu olaydan sonra “Ariane 5 Sendromu” terimi ortaya atıldı: test edilmemiş yeniden kullanılan kod riski.

Sonuç ve Dersler

  • Programlama dili (Ada) değil, yanlış yazılım tekrar kullanımı kazanın sebebidir.
  • Gerçek zamanlı, güvenlik-kritik sistemlerde test süreçleri hayati önem taşır.
  • Test edilen kod, test edilmeyen çevresel şartlarla çalıştığında sistem bütünü bozulur.
  • Felaketin maliyeti: 370 milyon dolar civarı.



Kapanış

Yazılım geliştirmenin sadece “kod yazmak” olmadığının çarpıcı bir örneği olan Ariane 5, bugün hala yazılım testi, doğrulama ve sistem entegrasyonu konularında eğitimlerde anlatılan bir vakadır.


Geliştiriciler için bir not: Çalışacağı ortamı tanımadan yazdığınız her satır, uzaydan bile dönebilir.