DO-178C temelli yazılım konfigürasyon yönetimi

TUSAŞ Motor Sanayii AŞ'nin (TEI) dergisi "TEI Post"un son sayısında (135), TEI’de Tasarım Mühendisliği Direktörlüğü altında, Konfigürasyon Yönetimi Takım Liderliğinde çalışan Sevcan Arslan’ın kaleme aldığı “DO-178C Temelli Yazılım Konfigürasyon Yönetimi” başlıklı yazısına yer verildi.

"TEI Post" dergisinin 135. sayısının tamamına, mobil uygulamamızın dergi bölümünden ulaşabilirsiniz.

Arslan’ın yazısını takipçilerimize sunuyoruz: 

DO-178C TEMELLİ YAZILIM KONFİGÜRASYON YÖNETİMİ

DO-178C Nedir?

1980’li yılların başlarında, uçak ve motorlarda kullanılan hava sistemleri ve ekipmanlarında yazılım kullanımının yaygınlaşmasıyla, uçuşa elverişlilik gereksinimlerine uyum için yazılım süreçlerini tanımlama ihtiyacı oluşmuştur. Bu ihtiyacı karşılamak amacıyla RTCA (Radio Technical Commission for Aeronautics), 1982 yılında DO-178 (Software Considerations in Airborne Systems and Equipment Certification) dokümanını yayımlamıştır. Doküman, deneyimler ışığında yapılan geri bildirimlerle bugüne kadar üç kez revize edilmiştir. 1985 yılında DO-178A, 1992 yılında DO-178B ve 2011 yılında DO-178C revizyonu yayımlanmıştır.

ICAO (International Civil Aviation Organization) tarafından oluşturulan, GATM (Global Avionics Traffic Management) anlaşmasına göre tüm sivil hava araçları, sivil havacılık otoritelerinin onayına tabidir. Yazılımlar için sivil havacılık otoritesi onayı, DO-178C dokümanına uygunluk anlamına gelmektedir. Bunun yanında günümüzde askeri hava ve uzay araçlarında, nükleer santrallerde, hatta deniz araçlarında, ya da genelleştirirsek, emniyet kritik sistem yazılımlarında, sistem emniyetinin bozulmaması için DO-178C uyumluluğu bir sözleşme maddesi olabilmektedir.

DO-178C dokümanının kullanılabilmesi için gerekli olan girdilerden biri, DAL (Development Assurance Level) atamasıdır. DAL ataması, yazılımın, emniyet analizleri sonucu belirlenen hata durumlarını oluşturma olasılıklarına göre yapılmaktadır.

• Seviye A: Yazılımın düzgün çalışmaması “ölümcül” bir hataya yol açabilir veya yol açmasına katkıda bulunabilir.

• Seviye B: Yazılımın düzgün çalışmaması “tehlikeli” bir hataya yol açabilir veya yol açmasına katkıda bulunabilir.

• Seviye C: Yazılımın düzgün çalışmaması “önemli” bir hataya yol açabilir veya yol açmasına katkıda bulunabilir.

• Seviye D: Yazılımın düzgün çalışmaması “az önemli” bir hataya yol açabilir veya yol açmasına katkıda bulunabilir.

• Seviye E: Yazılımın düzgün çalışmaması “etkisiz” bir hataya yol açabilir veya yol açmasına katkıda bulunabilir.

DO-178C hedef bazlı bir dokümandır. Yazılım seviyesine göre karşılanması beklenen hedef sayısı, dolayısıyla yazılım maliyeti artmaktadır. İdeal olarak DO-178C uyumlu yazılım geliştirmenin getirdiği ekstra maliyetin, toplam yazılım maliyetinin yaklaşık %40’ını geçmemesi beklenmektedir. Fakat yanlış uygulamalar sonucu bu oranın %200’leri bulduğu görülmüştür. Sağladığı faydalardan bazıları ise şunlardır;

• Daha az kod iterasyonu,

• Yazılımda daha yüksek tutarlılık,

• Entegrasyon sırasında daha az hata,

• Gelişmiş konfigürasyon yönetimi,

• Gelişmiş donanım entegrasyonu,

• Daha yüksek müşteri memnuniyeti,

• Daha yüksek tekrar kullanılabilirlik.

DO-178C; yazılım ve dolayısıyla sistem güvenilirliğini artırması, tekrar kullanılabilirlik sağlaması, tedarikçi tutarlılığı ve şeffaflığı gibi katkılarından dolayı savunma sektöründe de kabul görmüştür.

DO-178C, süreçlere odaklanarak yazılım kalitesini güvence altına almayı hedeflemektedir. DO-178C dokümanında aşağıdaki süreçler ele alınmıştır;

• Yazılım planlama süreci

• Yazılım geliştirme süreci

• Yazılım doğrulama süreci

• Yazılım konfigürasyon yönetimi süreci

• Yazılım kalite güvence süreci

• Sertifikasyon süreci

DO-178C’ye göre Yazılım Konfigürasyon Yönetimi Nedir?

Yazılım konfigürasyon yönetimi, yazılım yaşam döngüsünün başından sonuna kadar devam eden; üretilen veriyi ve yapılan güncellemeleri kontrol altında tutarak, aynı çıktının tekrar üretilebilmesini sağlamayı ve verimliliği artırmayı amaçlayan entegre bir süreçtir. Genel inanışın aksine, yazılım konfigürasyon yönetimi, sadece kaynak kod için değil; yazılımı üretmek, doğrulamak ve uyum gösterimini yapmak için üretilen tüm veri ve dokümantasyon için uygulanır. Diğer bir deyişle, tüm yazılım yaşam döngüsü verisi, yazılım konfigürasyon yönetimine tabidir.

Yazılım konfigürasyon yönetimi faaliyetlerinin ne kadarının uygulanacağını belirlemek üzere, kontrol kategorileri tanımlanmaktadır.

Kontrol kategorisi 1 (KK1) ve kontrol kategorisi 2 (KK2) olmak üzere iki kategoride ele alınmaktadır. Konfigürasyon kontrolü altına alınacak tüm verilere, yazılım seviyesi ve verinin doğasına göre kategori ataması yapılmaktadır. Yazılım konfigürasyon yönetimi faaliyetlerinin, kontrol kategorilerine göre uygulama gereklilikleri yandaki tabloda görüldüğü gibidir.

KK1, kritik kategori olduğu için tüm yazılım konfigürasyon yönetimi faaliyetlerinin uygulanması gerekir. KK2 için uygulanması beklenen faaliyetler, KK1’in bir alt kümesinden oluşur.

Yazılım Konfigürasyon Yönetimi Neden Gereklidir?

Yazılım geliştirme projelerinde; mühendisler, kısıtlı takvim ve bütçeleri ile oldukça karmaşık sistemler geliştirmek durumunda kalmaktadır.

Değişikliklerin, yazılım kalitesine etki etmeden, hızlıca yapılması gerekir. Bu noktada konfigürasyon yönetimi; kaynak kodun bütünlüğü, dosyaların versiyon takibi ve erişilebilirliği, giderilen hataların tekrarlamaması, gereksinimlerin karşılandığının garanti altına alınması ve neyin ne zaman değiştiğinin takibi gibi konularda destek olmaktadır. Konfigürasyon yönetimi gerektiği gibi uyguladığında sağlayacağı faydalardan bazıları şunlardır;

• Yazılım bütünlüğünün idamesini sağlar,

• Sertifikasyon otoritesi ve müşteri nezdinde güven tesis eder,

• Yazılımın daha kaliteli dolayısıyla daha emniyetli olması için destek olur,

• Proje bütçesine ve takvimine katkı sağlar,

• Tanımlama, kayıt, problem giderme için altyapı sağlar,

• Geliştirme, doğrulama, test ve yeniden üretim için kontrollü ortamlar kullanılmasını sağlar,

• Yıllar sonra bile yazılımın yeniden oluşturulabilmesini sağlar,

• Proje boyunca durum muhasebesi yapılabilmesini sağlar,

• Proje sonunda yazılımın kabulü için gerekli veriyi sağlar,

• Uzun vadeli bakım olanağı sağlar.

Zayıf bir konfigürasyon yönetimi; zaman, para, kalite ve güvenilirlik kaybına sebep olabilmektedir.

Yazılım Konfigürasyon Yönetimi Kimin Sorumluluğudur?

Yazılım konfigürasyon yönetimi, yazılım geliştirme sürecinde görev alan herkesin sorumluluğundadır. Yazılım konfigürasyon yönetimi altyapısı oluşturulurken birçok faktör göz önünde bulundurulmalıdır. Bir yandan konfigürasyon yönetimi gerekliliklerini karşılarken diğer yandan geliştirme ekibinin pratiklerine uyum sağlayacak süreçler kurgulanmalıdır. Konfigürasyon yönetimi sürecinin başından sonuna kadar, takım çalışması ve iletişim, büyük önem taşımaktadır. Ekiplere, süreçle alakalı gerekli eğitim desteği verilmeli ve sorumlu oldukları noktalar vurgulanmalıdır.

Yazılım Konfigürasyon Yönetimi Faaliyetleri Nelerdir?

• Konfigürasyon Tanımlama: Konfigürasyon tanımlama, her bir yazılım yaşam döngüsü verisine, benzersiz numara, isim ve versiyon ataması yapılarak diğer konfigürasyon yönetim faaliyetleri için kullanılabilir hale getirilmesidir. Tanımlanamayan bir şeyi kontrol etmek mümkün olmadığı için konfigürasyon tanımlama, diğer konfigürasyon yönetimi faaliyetleri için bir başlangıç noktasıdır.

• Ana hat: Ana hat; yazılım ve ‘yazılım yaşam döngüsü verisinin” projenin herhangi bir anındaki durumudur. Bir veya daha fazla konfigürasyon biriminin onaylı ve kayıtlı konfigürasyonu olup bir sonraki geliştirme aktivitesi için temel oluşturur. Genellikle geliştirme fazlarının sonlarında, resmi gözden geçirme sonucu çekilir ve faz kapatılır. Çekilecek ana hatlar, kullanılan yazılım yaşam döngüsü modeline göre değişiklik göstermektedir.

• İzlenebilirlik: İzlenebilirlik, değişikliğe uğramış ve versiyon atlamış konfigürasyon birimi ya da ana hattın eski versiyonları ile ilişkisinin kayıtlı ve takip edilebilir olmasıdır. Değişiklik yönetimi ile yakından ilişkilidir.

• Problem Raporlama: Problem raporlama, projenin herhangi bir aşamasında tespit edilen süreç uygunsuzlukları veya yazılımda tespit edilen hataların tanımlamasıdır. Değişiklik yönetiminin yapılabilmesi ve bilinen sorunların zamanında giderilebilmesi için, etkili bir problem raporlama süreci tanımlanması gereklidir.

• Değişiklik Kontrolü - Bütünlük ve Tanımlama: Konfigürasyon birimi ya da ana hattın değişikliğe karşı korunarak, bütünlüğü muhafaza edilmelidir. Değişiklik olması durumunda konfigürasyon tanımında (versiyonunda) değişiklik yapılması gerekir.

• Değişiklik Kontrolü – İzleme: Değişiklik kontrolüne giren konfigürasyon birimlerine ve ana hatlara yapılan değişikliklerin onaylı ve kayıtlı olması gerekmektedir. Değişikliklerden etkilenen süreç ya da yazılım yaşam döngüsü verisi varsa, değerlendirilmesi ve çıktısı etkilenen tüm süreçlerin tekrarlanması gerekir.

• Değişiklik İnceleme: Raporlanan problemin ve önerilen değişikliğin sistem gereksinimlerine etkisinin değerlendirilip, sistem emniyet değerlendirmesi de dahil olmak üzere sistem süreçlerine bilgi verilmeli ve cevapları incelenmelidir. Yapılacak değişiklikler tanımlanmalı ve değişiklik sonucu konfigürasyon birimlerinin versiyonlarının değiştiği teyit edilmelidir.

• Konfigürasyon Durum Değerlendirme: Yayımlanmış konfigürasyon birimlerinin, ana hatların, problem raporlarının, değişiklik taleplerinin mevcut durumlarının raporlanması faaliyetidir. Yönetici, geliştirici ve paydaşları bilgilendirmek amacıyla yapılmaktadır.

• Geri Alma: Arşivlenen yazılım yaşam döngüsü verisinin, ihtiyaç duyulduğunda erişilebilir olması gerekmektedir.

• Yetkisiz Değişikliklere Karşı Koruma: Yazılım yaşam döngüsü verisinin yalnızca yetkili kişiler tarafından değiştirilebilir olması gerekmektedir.

• Depolama Ortamı Seçimi, Yenileme, Yedekleme: Arşiv medyası, veri kaybı riskini en aza indirecek şekilde seçilmelidir. Zamana bağlı hasarların önüne geçmek amacıyla periyodik olarak kontrol edilmelidir. Yedeklenen veri, iki kopya halinde ve afet riskine karşı, fiziksel olarak ayrı yerlerde muhafaza edilmelidir.

• Yayım: Yayım, resmi olarak erişim ve yetki dahilinde kullanıma açma faaliyetidir. Bazı verilerin yayımlanması gerekirken bazılarının yalnızca saklanması ve korunması yeterlidir. DO-178C, bu ayrımı kontrol kategorileri ile yapmaktadır.

• Veri Saklama: Üretilen ve arşivlenen verinin gereken süre boyunca saklanması gerekmektedir. Bu süre, uçuşa elverişlilik gereksinimleri ve yazılım bakım süresi göz önünde bulundurularak belirlenir.

Yazılım Konfigürasyon Yönetim Araçları

Yazılım konfigürasyon yönetimi; geçmişte manuel yürütülen ve zaman kaybına neden olan bir süreçken, yazılım konfigürasyon yönetimi araçlarının geliştirilmesi ile yük olmaktan çıkmıştır. Yazılım konfigürasyon yönetimi aracı tek başına, tüm hedeflerin karşılanmasını sağlayamaz, yazılım konfigürasyon yönetimi etkinliği ve yeterliliğinin sağlanabilmesi için süreçlerin doğru kurgulanmasının yanı sıra süreç adımlarında insan dikkati ve doğru karar alma yetisi de önem kazanmaktadır.

Piyasada, birçok yazılım konfigürasyon yönetimi aracı bulunmaktadır. Organizasyonun büyüklüğü, projenin ihtiyaçları gibi konular göz önünde bulundurularak en uygun araç seçilmelidir. Kullanılan aracın kabiliyetlerinin oldukça iyi bilinmesi ve farklı ihtiyaçlar doğrultusunda konfigüre edilebilmesi, alınan verimi artıracaktır.

TEI’de Yazılım Konfigürasyon Yönetimi

Tasarım Mühendisliği Direktörlüğü, Pistonlu Motorlar Tasarım Müdürlüğü bünyesinde başlayan yazılım konfigürasyon yönetimi çalışmaları, daha sonra Elektrik, Elektronik, Kontrol ve Gömülü Sistemler Müdürlüğü bünyesine alınmıştır. 2017 yılında ise özgün ürün tasarım projelerinin konfigürasyon yönetimi için tek çatı altında ve bağımsız olarak hizmet vermek üzere kurulmuş olan Tasarım Bütünlüğü ve Uçuşa Elverişlilik Kıdemli Takım Liderliği, Konfigürasyon Yönetimi Takım Liderliği bünyesinde yerini almıştır.

TEI’de yazılım konfigürasyon yönetimine yönelik çalışmalara, Operatif İHA Motoru Geliştirme Projesi ile birlikte ağırlık verilmiştir. Süreçler; DO-178C ve DAL-C ile uyumlu olarak kurgulanmış olup 2016 yılında, Yazılım Konfigürasyon Yönetimi Planı ile otorite onayına sunularak uygunluğu teyit edilmiştir.

Yazılım konfigürasyon yönetimi için kullanılan araçlar şöyledir;

Visual SVN Server / Tortoise SVN: Versiyon takip aracı olarak kullanılmaktadır. Versiyonlar arası farkları görüntüleyebiliyor olması, en alt dizine kadar yetki kontrolüne olanak sağlaması, JIRA ile entegre olabilmesi gibi özelliklerinden dolayı tercih edilmiştir. Yazılım konfigürasyon yönetiminde aktif olarak kullanılmaktadır.

Atlassian JIRA Software: Yazılım dünyasına yönelik geliştirilmiş olan süreç yönetim aracıdır. İş akışlarındaki esnekliği sayesinde, yazılım konfigürasyon yönetimi için kurgulanan süreçlere uygun konfigüre edilebilmektedir. Yine bir Atlassian ürünü olan Fisheye sayesinde SVN ile entegre edilmiş ve sertifikasyon sürecinin önemli adımlarından biri olan kanıt gösterimi konusunda büyük fayda sağlamaktadır.

IBM Rational DOORs: Gereksinim yönetimi aracıdır. Araç üzerinde geliştirilen gereksinimler, konfigürasyon birimi olarak ele alınmaktadır. DOORs üzerinde geliştirilen konfigürasyon birimlerinin versiyon takibi yine bu araç üzerinde yapılmaktadır. DXL Script çalışmaları ile kabiliyetleri artırılıp, izlenebilirlik hedefini karşılaması sağlanmıştır. Tasarım ekibinin pratikleri ve DO-178C gereklilikleri göz önüne alınarak kurgulanan süreçler ve deneyimler ışığında iyileştirilmeye devam edilmektedir.