Herşey bir gaz ve toz bulutuydu.. Peki o kadar eskiye gitmeyelim, 1985 yılında DO-178A'nın çıkmasını da hızlıca geçecelim ve gelelim A nın geliştirilmesi ile ortaya çıkan B sürümüne. DO-178B RTCA tarafından yayınlanan "Software Considerations in Airborne Systems and Equipment Certification" başlıklı bir döküman. Başlıktanda anlaşılacağı üzere ilgi alanı yazılımların uçuşa elverişlilik gereksinimlerini karşılaması. Bu gereksinimlerin nasıl karşılanacağı ise tamamen geliştiriciye bırakılmıştır. - O kadar da rahat hissetmeyelim kendimizi zira DO-178B gereksinimlerini karşılamak ciddi ölçüde duygusallık ( $ ) gerektirecektir.-
Uçuşa elverişlilik gereksinimleri, hava aracında koşan yazılımın hata yapması durumunda sistem güvenliğininin nasıl etkileneceği üzerinde durur. Yahu etkilese etkilese ne kadar etkileyecek yazılım olmadan da gitmez mi kardeşim bu araç diyenler için hemen bir kaç örnek verebiliriz. (bu kısma bayılıyorum sallanan sandalyesinde saçı sakalına karışmış ihtiyarın 1960 dan beri oraya giden kimse geri dönmedi demesi gibi)
Örnek 1: Uçağın eğlence sistemindeki video oynatıcı yazılımın arızalanması.
Olası Sonuç: Mutsuz, sinirli ama hala nefes alıp verebilen yolcular.
Örnek 2: 0 görüş durumunda (sis vs.) aletli otomatik iniş esnasında uçağı kontrol eden yazılımın hata yapması.
Olası Sonuç: Ne olduğunu bile anlamadan yarı yanmış halde kimi enkaza sıkışmış kimi piste saçılmış yolcular.
Durumun ciddiyetinin daha iyi anlaşılması açısından verdiğim bu iki örnek hem bu işin şakasının olmadığının hem de farklı işleri üstlenmiş yazılımların farklı güvenlik seviyelerine sahip olması gerektiğinin güzel bir ispatı. Uçağın eğlence sistemi ile otomatik iniş sistemi yazılımlarının hata yapması durumunda sistemin güvenliği farklı şekilde etkilenmektedir. Bu sebepten iki farklı yazılım iki farklı gereksinim setine göre geliştirilmeli ve test edilmelidir.
İşte DO-178B bu farklı gereksinim setlerini ifade etmek açısından yazılım sistemlerini 5 seviyede tanımlar.
Level A : Hata yapması durumunda ölümcül (Catastrophic) sonuçlar ortaya çıkaran yazılımlar.
Level B : Hata yapması durumunda tehlikeli/riskli (Hazardous)sonuçlar ortaya çıkaran yazılımlar.
Level C : Hata yapması durumunda ciddi olabilecek(Major) sonuçlar ortaya çıkaran yazılımlar.
Level D : Hata yapması durumunda daha az risk oluşturabilecek sonuçlar (Minor)ortaya çıkaran yazılımlar.
Level E : Hata yapması durumunda risk oluşturmayan yazılımlar.
Sistem güvenlik değerlendirmesi (safety assessment) ve etki analizleri tamamlandığında yazılma yukarıda bahsettiğim seviyeler tanımlanır. Sistem güvenlik değerlendirmesi ve etki analizlerinin nasıl yapıldığı konusuna bir başka yazımızda değineceğiz, bu noktada dikkat edilmesi gerekenin bu sürecin ciddi analizlerin ve değerlendirmelerin yapıldığı ve yazılıma bir seviye tanımlandığı kritik bir süreç olduğudur. Malesef ülkemizde özellikle yüklenici-altyüklenici ilişkili durumlarında yeterince özen gösterilmeden yapılan kırılımların ve seviyelerin belirlendiği örnekler mevcut olup bu durum zaman, işgücü ve para kaybının yanında hava araçlarında güvenlik zafiyeti oluşturmaktadır.
Seviye A olan bir yazılımda tamamlanması gereken hedef sayısı 66, B de 65 ve C seviye bir yazılımda hedef sayısı 57 olduğu göz önünde bulundurulursa gereksiz yere yüksek seviye belirlenmiş bir yazılımın geliştirme ekibi fazladan hedefler tamamlamak zorunda kalacak, tamamlanması gereken her bir hedef firmaya binlerce dolara mal olacaktır. Tersi istikamette ilerlenirse olması gerekenden daha düşük seviyelendirilmiş bir yazılım hava aracı için risk teşkil edecek, kontrolü yapılmayan bir olasılık sebebi ile can ve mal kaybına neden olabilecektir.
Peki DO-178B kılavuzluğunda yazılım geliştirmek, geliştirdiğimiz yazılımları güvenli yapar mı? Belki..
DO-178B 'nin hataların önlenmesi konusunda ciddi hedefler koyduğu kesin fakat bu ortadan kaldıracağını garanti etmiyor. İşin ilginç yanı yapılan araştırmalar gösteriyor ki meydana gelen uçak kazalarının büyük bir kısmı sistemlerin hiç çalışmamasından değil yanlış çalışmalarından ve diğer sistemlerin yanlış çalışan bu sistemlere güvenmelerinden kaynaklanıyor. Örn: Türk Hava Yollar TK-1951 sefer sayılı Hollanda uçağı Schiphol havaalanına iniş yaparken düşmüş 135 kişi hayatını kaybetmişti. Kaza kırım raporu incelendiğinde uçağın radar altimetresinin uçağın yükseklik bilgisini yanlış ölçtüğü, otomatik pilotun bu yükseklik verisine güvenerek motor gücünü ve hızı kestiği ve uçağın piste ulaşmadan yere çakıldığı görülüyor.
DO-178B hatasız yazılımı garanti etmese de izlemensini önerdiği metodolojiler ile ortaya çıkabilecek bu hataların çok önceleri tespit edilmelesine olanak sağlıyor. Nasıl mı? Kontrol..Tekrar kontrol..Ve tekrar kontrol..Ve yine kontrol..
Önceden tanımlanmış hedefler yazılım geliştirmenin doğasında olan tuzaklara düşülmemesi için geliştiricele yol gösterir. Her biri birer hedef olan aşağıdaki süreçler DO-178B nin bel kemiğini oluşturur.
- Planlama Süreci (Planning Process)
- Geliştirme Süreci (Development Process)
- Gereksinim Süreci (Requirement Process)
- Tasarım Süreci (Design Process)
- Kodlama ve Entegrasyon Süreci (Codding Integration Process)
- Test ve Doğrulama Süreci (Test and Verification Process)
- Konfigürasyon Süreci (Configuration Process)
- Kalite Güvence Süreci (Quality Assurance Process)
Pek çok geliştiricinin hali hazırda tanıdık olduğu bu süreçler DO-178B de bazı farklılıklar ile ele alınır. Bir sonraki yazımızda DO-178B kapsamında adım adım her bir sürecin nasıl ele alınması gerektiğini, genelde nasıl ele alındığını ve sıklıkla düşülen hataları ve sonuçlarını irdeleyerek açıklamaya çalışacağım.
