DO-178B ve DO-178C yazılım sertifikasyon standartları, uçuşa elverişli hava sistemleri üretmek için bir kılavuz görevi görmektedir. İlk kez 1992’de yayınlanan DO-178B (Software Considerations in Airborne Systems and Equipment Certification), yazılım tabanlı hava sistemleri için ticari amaçlı EASA (European Union Aviation Safety Agency) ve FAA (Federal Aviation Administration) gibi otoritelerden gerekli sertifikasyonu almak için dikkate alınan önemli bir belgeydi. Ancak Federal Havacılık Düzenlemeleri, 2013 yılında DO-178C’yi uçuşa elverişlilik uygunluğunu gösteren bir yöntem olarak kabul etmiştir. DO-178B ve DO-178C standartları hakkında daha genel bilgi almak için bu makaleyi okuyabilirsiniz.
DO-178B veya DO178C standartları aşağıda örnek olarak belirtilen belgeler ve daha fazlası tarafından sağlanmalıdır.
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
DO-178B ve DO-178C standartlarını karşılamak için gereken belgeler bunlarla sınırlı değildir. Uçuşa elverişliliği zenginleştirecek çok sayıda başka dokümanlar bulunmaktadır. Bu dokümanları buradan kontrol edebilir ve satın alabilirsiniz.
DO178 Dokümanları
PSAC Dokümanı
PSAC (Plan for Software Aspects of Certification) dokümanı, yaşam döngüsü verilerini ortaya çıkarmanın yanı sıra, izlenecek gerekli standartları, süreçleri, protokolleri ve metodolojileri açıklamaktadır. Böylece DO-178 standartları karşılanabilmektedir. PSAC ayrıca yazılım geliştirme takvimini ve sistemin genel durumunu da belirtmektedir. Hem onaylayan makam hem de başvuru sahibi bu belgeden yararlanır. PSAC, ilk yazılım planlama sürecinde üretilmeli ve yetkili makam tarafından onaylanmalıdır. PSAC dokümanımızı kontrol etmek için lütfen buraya tıklayın.
SDP Dokümanı
SDP (Software Development Plan) dokümanı geliştirme prosedürleri, protokolleri, standartları, yaşam döngüleri ve geliştirme ortamı gibi gerekli bilgilerin belirlenip belirlenmediğini kontrol etmeyi amaçlar. SDP dokümanı, yazılım planlama sürecinin önemli bir parçasıdır. SDP dokümanımızı kontrol etmek için lütfen buraya tıklayın.
SVP Dokümanı
SVP (Software Verification Plan) dokümanı uygun bir sürüm kontrolü sağlayarak, gerekli test senaryolarını ve kapsamlarını, prosedürleri, protokolleri, gereksinim doğrulamasını ve kaynak kodu doğrulamasını belirtir. SVP aynı zamanda planlama sürecinin önemli bir parçasıdır. SVP dokümanımızı kontrol etmek için lütfen buraya tıklayın.
SCMP Dokümanı
SCMP (Software Configuration Management Plan) dokümanı planlama sürecinin bir diğer önemli elemanıdır. Yazılımın geliştirme süreci boyunca ilk hazırlanan plan çoğu zaman değişikliğe uğramaktadır. SCMP, bu değişiklikleri algılamamıza, kontrol etmemize, sürdürmemize ve izlememize yardımcı olur. Yazılım geliştirme süreci boyunca uygulanır. SCMP, hatayı en aza indirmeyi ve verimliliği en üst düzeye çıkarmayı amaçlar. Ekip üyeleri değişiklikleri raporlamak ve birbirlerine bildirmek için çaba göstermelidir. SCMP dokümanımızı kontrol etmek için lütfen buraya tıklayın.
SQAP Dokümanı
SQAP (Software Quality Assurance Plan) dokümanı bir ürün veya hizmetin SRS’de (Software Requirement specification) verilen özelliklerin karşılamasını sağlamak için kullanılan araçları, yöntemleri ve teknikleri içermektedir. SQAP, projede Yazılım Kalite Güvence Faaliyetlerinin nasıl yürütüleceğini açıklar. SQA ekibi kilometre taşları oluşturur ve her kilometre taşında projenin kalitesini değerlendirir. SQA, yazılım yaşam döngüsü boyunca yürütülür. SQAP dokümanımızı kontrol etmek için lütfen buraya tıklayın
SAS Dokümanı
SAS (Software Accomplishment Summary) geliştirme ve onaylama süreçleri sırasında yazılım bileşenlerinin her adımını özetler. SAS, onaylama araçları kalifikasyonunun bulgularının özetini içermelidir. FAA, SAS hakkında bilgilendirilmelidir. Bu, sertifika yetkilisinin onaylama verilerinin bulgularının doğrulamasını sağlar ve aracın kalifikasyon durumunun kanıtı işlevi görür. SAS dokümanımızı kontrol etmek için lütfen buraya tıklayın
ARP4754 Standartları ve DO178 Standartları
ARP4754, “Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems” anlamına gelmektedir. ARP4754 Standartları, uçak sistemleri için bir bütün olarak rehberlik sağlarken, DO178 Standartları sadece uçuş yazılımları için kullanılmaktadır. Her iki standart da FAA ve EASA gibi otoriteler tarafından kabul edilmektedir.
ARP4754, 1996 yılında SAE (Otomotiv Mühendisleri Derneği) tarafından geliştirilmiş ve yayınlanmıştır. 2010 yılında SAE, Sivil Hava Araçları ve Sistemleri Geliştirme Yönergeleri anlamına gelen ARP4754A‘yı yayımlamıştır. ARP4754A, uçak ve sistem seviyelerinde kullanılan tasarım güvencesi fikrini zenginleştirir ve aynı zamanda geliştirme güvencesi kelimesinin kullanımını standartlaştırır. ARP4754, Kasım 2011’de FAA tarafından onaylanmıştır.
ARP4754, gereksinimlerin belirlenmesinden entegrasyon ve onaylama süreçlerinin sonuna kadar tüm uçak geliştirme döngüsünü kapsar. ARP4754, uçak, sistem ve bileşenler için soyutlama sağlar. Bileşen tasarımı için ARP4754, DO-178 ve DO-254’e açıkça atıfta bulunur. ARP4754, geliştirme, tasarım ve onaylama gibi farklı süreçler boyunca güvenlik değerlendirmesine odaklanır. Bununla birlikte, ARP4754’ün yazılım veya elektronik donanım geliştirme, hizmet içi emniyet faaliyetleri ve uçak yapısal geliştirme sürecinin belirli bir kapsamını içermediğine dikkat edilmelidir.
Tasarım Süreçleri
Ön Tasarım Değerlendirmesi (PDR)
Ön tasarım, yazılım geliştirme sürecinin önemli bir aşamasıdır. Ön tasarım sırasında, sistem mimarisini oluşturmak için üst düzey gereksinimler ve kullanım durumları belirlenir. Arayüz, veritabanı ve mimari için belgeler ve bileşen ilişkileri için diyagramlar tasarımda kullanılabilir. Ön tasarım, bu girdilere dayalı olarak projenin başlangıcında sistemin görsel bir tasvirini sunacaktır. Ön tasarım ayrıca aşağıdaki daha detaylı tasarım aşamaları için zemin hazırlar. Bir taslak olarak görülebilir.
Ön Tasarım İncelemesi (PDR), projenin ön tasarım aşamasını sona erdirir. Detaylı tasarımla ilerlemek için PRD yeterli güvence sunmalıdır. PDR’nin amacı, ön tasarımın ve temel sistem mimarisinin eksiksiz olmasını, gereksinimlerin bütçe ve program dahilinde karşılanabileceğine dair teknik güvenin bulunmasını sağlamaktır.
Kritik Tasarım Değerlendirmesi (CDR)
Kritik Tasarım Değerlendirmesi (CDR), projenin kritik tasarım aşamasını sona erdirir. Nihai tasarımlar, kapsamlı analiz, simülasyonlar, şemalar, yazılım kodu ve test verileri aracılığıyla CDR ile sunulur. CDR, sistemin test ve üretime geçebilmesini sağlar. Söz konusu ihtiyaçların bütçe ve zaman çizelgesi dahilinde karşılanabileceğini de ifade etmektedir. Ortaya çıkan kapsamlı çizimler ve spesifikasyonlar, nihai bir temel ile birlikte bir başlangıç ürün temel çizgisi sağlar. CDR geniş kapsamlı ve ayrıntılı olmalıdır.
Nihai Tasarım Süreci
Nihai Tasarım Süreci, projedeki her bir bileşenin ayrıntılı mimari ve mühendislik çizimlerini sağlar. Bazı projeler için nihai tasarım raporunun oluşturulması gerekebilir. Tespit edilen tasarım problemleri, nihai tasarım aşaması tamamlanmadan önce çözülmelidir. Çizimler ve rapor, planlanan tahminleri mümkün kılmak için yeterli ayrıntıyı sunmalıdır. Nihai tasarım raporu, güncellenmiş bir zaman çizelgesi, maliyet tahminleri ve spesifikasyonları içermelidir. Ayrıca, projenin ekonomik olarak fizibilitesinin de onaylanması gerekir. Nihai Tasarım Aşamasında yapılacak herhangi bir değişiklik, diğer aşamalara göre daha maliyetlidir. Bu nedenle çok dikkatli bir şekilde gerçekleştirilmelidir.
SOI (Stages of Involvement)
Projelerin DO-178B uygunluğunu değerlendirmek için projenin planlama, geliştirme ve onaylama gibi çeşitli aşamalarında ilgili ülkelerin havacılık otoriteleri tarafından SOI değerlendirmeleri yapılmaktadır. İdeal durumlarda, toplam dört SOI incelemesi planlanmaktadır.
İlk SOI değerlendirmesi projenin belgelendirme uyum çalışmalarının planlama aşamasını içerir. İkinci SOI incelemesi, projenin geliştirme aşamalarına odaklanmaktadır. Üst düzey yazılım gereksinimlerinin geliştirilmesiyle başlayarak, tasarımın, alt düzey yazılım gereksinimlerinin ve kaynak kodunun DO178B’ye uygun üretilip üretilmediğini sorgular. Üçüncü SOI incelemesi, doğrulama aşamalarına odaklanır. Sadece test faaliyetleri değil, doğrulama amacıyla gerçekleştirilen tüm faaliyetler incelenir. Dördüncü SOI ise, projenin sonlarına doğru yapılan, açıkta kalan herhangi bir faaliyet olup olmadığını ve önceki değerlendirmelerden bu yana yeni bir sorun ortaya çıkıp çıkmadığını sorgulayan kapanış değerlendirmesidir.
DO-178B’nin planlama aşamasında üretilen yazılım ürünlerinden beklentisi, otorite ile bunu yapan firma arasında ortak bir kural seti üzerinde anlaşmak ve proje boyunca bu kural setine uymaktır. Diğer bir deyişle, plan ve standartlar yazarken şirket sadece kendi süreçlerini belirlemekle kalmaz, aynı zamanda otoritenin kendini belgelendirme süreci boyunca nasıl değerlendireceğine dair kuralları da yazar.
Yazar: Can Önal ([email protected])
Mor Teknoloji
