DO-178B Planlama

DO-178B modeline bakacak olursak;

• Planlama Süreci
• Geliştirme Süreci
• Doğrulama
• Konfigürasyon Yönetimi
• Kalite Güvence
• Sertifikasyon

şeklinde bir sıralama yapabiliriz. DO-178B kılavuzluğunda ilerlenen projelerde planlama en kritik ve ekip olarak üzerinde en çok kafa yorulması gereken süreçtir. Planlama sürecini kritik yapan konu DO-178B'nin aksi ispatlanana kadar herşey suçludur prensibidir. Modern hukuk anlayışında "aksi ispatlanana kadar herkes masumdur" prensibi DO-178B süreçlerinde tam tersidir ve siz planlarda ifade ettiğiniz tüm maddelerin planlarda geçen şekli ile yapıldığına dair otorite karşısında savunma yapmak ve delil sunmak zorundasınızdır. Pek çok firmanın planlama süreci çıktısı plan dökümanları yap ve unut prensibi ile oluşturulduğundan (plan dökümanlarının değişiklik kayıtlarına bakıldığında çoğunlukla hiç değiştirilmedikleri görülür) bu durum projenin sertifikasyon aşamasında soğuk terler dökülmesine sebep olmaktadır.

DO-178B planlama süreci 5 adet planı ve standart dökümanlarını kapsar:

1- PSAC (Plan for Software Aspects of Certification)
     Projenin maksadı, süreçleri, süreç geçiş şartları, kullanılacak teknoloji, geliştirme araçları vb. gibi konular fazla detaya girilmeden açıklanır. Proje takvimi nasıl, personel görev tanımları, ne tür bir işletim sistemi kullanılacak gibi soruların yanıtlarının PSAC içerisinde verilmesi beklenir. Detaya girilmemesi acizane benim tavsiyem olup projenin başında ve sonunda onaylanan PSAC 'in detaylı yazılması yazılım geliştirmenin değişken doğası (değişen müşteri isterleri, teknoloji vs.) düşünüldüğünde sıkıntılar ortaya çıkartmaktadır. Projenizde hangi aracı kullanacağınızı bu dökümanda anlatabilirsiniz fakat bu aracın detayları ve diğer araçlar ile olan entegrasyonunu döküman içerisinde anlatırsanız ve projenin 2.yılında detaylarıyla anlattığınız aracınızın versiyon değişimi dahi sizin için problem olabilir. 20-30 sayfalık bir PSAC yeterli olacaktır.

Dökümanın genel bakışı aşağıdaki gibidir, (başlıkları ingilizce bırakacağım)

1. System Overview: Sisteme genel bakış, sistemin fonksiyonalitesi yazılım/donanım dağılımı, arayüz tanımları vs. kısımlar burada anlatılır. 
2. Software Overview: Bu kısımda yazılım fonksiyonları emniyet isterleri gözetilerek ifade edilir. Kaynak yönetimi, hata dayanım, zaman kısıtları vb.
3. Certification Considerations: Atanmış DAL (design assurance level) değerine uygunluğun nasıl sağlanacağı anlatılır.
4. Software Lifecyle: Uygulanacak yazılım geliştirme süreci bu kısımda anlatılır. Her bir süreç aşamasının amacı ve bu amaca nasıl ulaşılacağı ifade edilir.
5. Software Livecycle Data: Bir önceki adımda bahsedilen süreç adımlarının her biri için giriş/çıkış koşulları ve ürünler (data) anlatılır.
6. Schedule: Proje takvimi anlatılır böylelikle sertifikasyon otoritesi ile gözden geçirme tarihleri planlanır.
7. Aditional Consideration: Bu kısımda projenin ilerleyişinde ve emniyet istelerinin karşılanmasında etkili olabilecek varsa araç kalifikasyonu, COTS ürünler vb konulardan bahsedilir.

Özetle PSAC dökümanının içermesi gereken bilgiler yukarıdaki gibidir, döküman şablonu internetten temin edilebileceği için burada paylaşmayacağım ve bir sonraki plan dökümanı olan "QA Plan" yani kalite yönetim planını izah etmeye çalışacağım.

Kalite planına geçmeden önce yazılım emniyet ve güvenilirliğinin ülkemizde yürütülen emniyet/görev kritik projelerde maliyet ve takvim kadar önemli bir kalem olduğunun anlaşılmasında güçlük çekildiği bu dönemlerde, emniyetin bir seçenek değil bir zorunluluk olduğu görüşümü paylaşan  meslektaşlarımı burada yad ederek Kalite Güvence Planından devam edelim.

2- Quality Assurance Plan

QA planı tüm süreç boyunca kalite güvencenin nasıl sağlanacağını anlatan plandır.CMMI bir firma için anlaşılması ve üretilmesi kolaydır, dikkat edilmesi gereken kalite planının 4. maddede anlatacağım yazılım geliştirme planı ile çelişmemesidir. DO-178B kılavuzluğunda ilerleyen projelerde bağımsız bir kaliteci şarttır. Bağımsız olmasının yani kalite temsilcisinin proje yönetimi dışında bir merciye rapor vermesinin gerekliliği işi yapan ile olmamış bu yeniden yapın diyenin farklı kişilere rapor vermesinin herkes için daha hayırlı olacağından ötürüdür. Zira bağlı olduğu proje yöneticisine şunları şunları yapmamışsınız ve ben bunu onaylamıyorum demek biraz sıkıntı oluşturabilir ;)

QA planı şirket plan ve standartlarının DO-178B ile uyumlu olduğunu ifade eder. Yazılım geliştirme sürecinin şirket planları ile uyumluluğunu garanti eder deliller içerir, gözden geçirmelerin nasıl yapılacağını ve süreçler arası geçiş kriterlerinin neler olduğunu belirtir. Genel bir ifade tarzı ile yazılması başka projeler kapsamında kullanılmasını kolaylaştıracaktır.

Bir sonraki adımda CM planını anlatarak devam edeceğiz..