Bağımsızlık konusu, DO-178C rehber dokümanının "Glossary" bölümünde aşağıdaki gibi tanımlanmıştır [1]:
Objektif değerlendirmeyi garanti altına almak adına sorumlulukların ayrılması
Tanımlamanın devamında, bağımsızlık konusunun "yazılım doğrulama aktiviteleri" ile "kalite güvence süreci" için uygulanabilir olduğu bilgisi verilmektedir.
DO-178C rehber dokümanı incelendiğinde, "yazılım doğrulama bağımsızlığı" konusunun "6.2 Overview of Software Verification Process Activities" başlığı altında, yazılım doğrulama aktivitelerinde göz önüne alınması gereken bir husus olarak listelendiği görülmektedir.
Yazılım Doğrulama Bağımsızlığının nasıl sağlanacağı, DO-178C "6.2 Overview of Software Verification Process Activities" başlığı altında şu şekilde tanımlanmaktadır [1]:
Her hangi bir doğrulama aktivitesi, doğrulama aktivitesine konu olan çıktıyı geliştiren kişiden farklı bir kişi/kişilerce veya araç kullanılarak yapıldığı durumda, doğrulama bağımsızlığı sağlanmış olacaktır.
Bağımsızlık konusu, "kalite güvence süreci" için ise, yazılım kalite güvence fonksiyonunun bağımsız olması ve düzeltici faaliyetlerin yapılmasını sağlama yetkisinin olması şeklinde tanımlanmaktadır. Şirketlerin geneli, kalite güvence bölümünü organizasyon yapılarında doğrudan genel müdüre bağlı ayrı bir bölüm olarak tasarlayarak, bu bağımsızlığı sağlamaktadır.
DO-178C rehber dokümanında Annex A bölümünde yer alan amaç tabloları incelendiğinde, DAL seviyelerine ait hangi amaçların doğrulama bağımsızlığı gerektiği bilgisinin olduğu görülmektedir. Aşağıdaki tabloda, her bir DAL seviyesi için, kaç adet amacın sağlanması gerektiği ile sağlanması gereken amaçların kaç tanesinin bağımsızlık gerektirdiği özet olarak yer almaktadır.
Yukarıdaki tablodan anlaşılacağı üzere, DAL seviyesi yükseldikçe bağımsızlık gerektiren amaç sayısı da artmaktadır. DAL seviyesi yükseldikçe bağımsızlık gerektiren amaç sayısı arttığından dolayı, doğrulama faaliyetleri için gerekli kaynak miktarı da artmaktadır. Dolayısıyla DAL seviyesi arttıkça yükselen proje maliyetlerinin ana sebeplerinden birisi de bağımsızlık gerektiren amaç sayısının artmasıdır.
Seviye C ve D için bağımsızlık gerektiren amaçlar incelendiğinde, sadece kalite güvence süreci ile ilgili amaçların bağımsızlık gerektirdiği görülmektedir. Seviye D için karşılanması gereken toplam 2 adet kalite güvence süreci amacının ikisi de bağımsızlık gerektirmektedir. Benzer şekilde, Seviye C için de karşılanması gereken 5 adet kalite güvence süreci amacının beşi de bağımsızlık gerektirmektedir.
Seviye A ve B'de ise, kalite güvence süreci amaçlarının yanısıra, bazı doğrulama aktivitelerinin de bağımsızlık sağlanarak yapılması gerekmektedir. Örneğin, DO-178C tablo A-4'te yer alan "Alt seviye gereksinimler, üst seviye gereksinimler ile uyumlu olmalıdır." amacının Seviye A ve B yazılımlar için bağımsızlık sağlanarak yapılması gerekmektedir.
Burada sık karşılaşılan bir yanlış anlaşılma ise, bağımsızlık konusunun şirket içinde veya proje içinde mutlaka ayrı bir grup kurularak sağlanması gerektiğidir. Buna yönelik olarak DO-248C dokümanında yer alan "4.19 DP#19 Independence in DO-178C/DO278A" başlığı incelendiğinde, bağımsızlığı sağlamak adına şirket içinde veya proje içinde ayrı bir grup kurulmasının zorunlu olmadığı açıkça belirtilmektedir [2]. Buradaki temel beklenti, daha önce de belirttiğimiz üzere, doğrulama faaliyetinin, doğrulama faaliyetine konu olan çıktıyı geliştiren kişiden farklı bir kişi veya araç tarafından yapılmasıdır.
DO-248C "4.19 DP#19 Independence in DO-178C/DO278A" bölümünde konuya ilişkin bazı örnekler de verilmektedir. Örneğin, alt seviye gereksinim testlerini geliştiren kişilerin, testlere konu alt seviye gereksinimlerin izlenebilirliği olan kod parçalarını yazan kişilerden farklı olması gerektiği belirtilmiştir [2]. Bir başka örnek vermek gerekirse, DO-178C tablo A-7'de Seviye A ve B yazılımlar için yapısal kapsama analizinin bağımsızlık sağlanarak yapılması gerektiği belirtilmektedir. Yapısal kapsama analizi sonucunda, eksik gereksinim ve eksik test gibi hususlar tespit edilebileceği için, yapısal kapsama analizi esnasında bağımsızlığı sağlamak adına, analizi yapan kişi/kişilerin, gereksinimleri geliştiren kişiler ile kapsama için koşturulan testleri geliştiren kişilerden farklı olması gerekmektedir.
Örneği somutlaştırmak gerekirse;
Seviye A olarak geliştirilen X projesinde;
ex1.c / ex2.c / ex3.c kaynak kod dosyalarının MC/DC kapsama analizi yapılacaktır.
ex1.c / ex2.c / ex3.c kaynak kod dosyalarının ex_LLR alt seviye gereksinim modülündeki gereksinimler ile izlenebilirlikleri mevcuttur.
ex1.c / ex2.c / ex3.c kaynak kod dosyalarının kapsama verisini almak için ex_LLR_Test isimli test prosedürü koşturulmuştur.
ex1.c / ex2.c / ex3.c kaynak kod dosyalarının geliştiricisi "Ali"
ex_LLR alt seviye gereksinim modülünün geliştiricisi "Ayşe"
ex_LLR_Test isimli test prosedürünün geliştiricisi ise "Ada"
Yukarıdaki senaryoda, test koşusu sonrasında ex1.c /ex2.c /ex3.c dosyalarının yapısal kapsama analizini "Ali", "Ayşe" ve "Ada" dışında yazılım geliştirme veya yazılım doğrulama faaliyetlerinde görevli bir mühendis yapabilir.
Sonuç olarak, test ve doğrulama ekiplerinin, yazılım geliştirme ekiplerinden farklı ve bağımsız olması yazılım literatüründe önerilen ve faydalı bir uygulama olmasına rağmen, DO-178C bağımsızlığı sağlamak adına böyle bir zorunluluk getirmemektedir. Firmaların özellikle seviye A ve B olan projelerde bu hususların farkında olmaları, kaynak planlaması ile proje ekibi içerisinde iş dağılımlarının uygun şekilde yapılmasını sağlayacaktır.
Kaynaklar:
[1] RTCA, “DO-178C Software Considerations in Airborne Systems and Equipment Certification”, 2011.
[2] RTCA, "DO-248C Supporting Information for DO-178C and DO-278A", 2011.
Yazılım emniyeti günümüzde hiç olmadığı kadar kritik önem arzeder oldu. Havacılık özelindeki değerlendirmeleri diğer alanlarda da yapmak hususunu atlamamak