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 gider kardeşim bu araç diyenler için (ki bir seminerde aynı ifadelerle başıma geldi) bir kaç örnek verebiliriz.
Örnek 1: Uçağın eğlence sistemindeki video oynatıcı yazılımın arızalanması.
Olası Sonuç: Mutsuz, belki 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 kimisi enkaza sıkışmış kimi piste saçılmış yolcular.
Durumun ciddiyetinin daha iyi anlaşılması açısından verdiğim 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ı emniyet seviyesine göre geliştirilmeli ve test edilmelidir.
İşte DO-178B bu farklı emniyet kritiklik durumlarını 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 yolcudan 9'u 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 izlenmesini önerdiği metodolojiler ile ortaya çıkabilecek bu hataların tespit edilebilmesine 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. CMMI Seviye 3 bir firma için DO-178B süreçlerini uygulamak normal şartlar altında %35-%40 ekstra maliyet getirir. Normal şartlarda diye ifade etmemin sebebi endüstri ortalamasının bu rakamın çok üzerinde %75 ile %150 arasında olduğu gerçeğidir. 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.
Hiç yorum yok:
Yorum Gönder