Yazılım hataları, yazılım geliştirme esnasında ortaya çıkan sistematik hatalardan kaynaklanmaktadırlar. Bu sebeple yazılım hataları, fiziksel parçalarda görülebilen ve kullanıma bağlı yıpranma-aşınma kaynaklı oluşan rastsal hatalardan(Random Failure) farklıdırlar. RTCA/ DO-178C “Software Considerations in Airborne Systems and Equipment Certification” rehber dokümanı, sistematik hataları önlemek üzere yazılım geliştirme süreçlerine yönelik belirli gereksinim ve kısıtlamaları tanımlayacak şekilde geliştirilmiştir. RTCA/ DO-178C rehber dokümanı da, diğer emniyet-kritik yazılım geliştirme standartları gibi, tasarım teminatı yaklaşımını temel almaktadır. Tasarım teminatı ile gereksinim, tasarım ve geliştirme aşamalarında ortaya çıkabilecek hataların sistem emniyeti açısından kabul edilebilir seviyeye indirildiğini garanti altına almak için uygulanan planlı ve sistematik aktiviteler kastedilmektedir[1]. Tasarım teminatı yaklaşımı, yazılım geliştirme esnasında uygulanacak süreçler ne kadar titiz ve sıkı olursa yazılımda o derece az hata kalacağı varsayımına dayanmaktadır[2]. Bu yaklaşımda, yazılımın kritiklik seviyesi yükseldikçe, uygulanan geliştirme ve doğrulama aktiviteleri nicelik ve nitelik açısından artmaktadır.
RTCA/DO-178C dokümanı incelendiğinde, yazılım konfigürasyon yönetimi sürecinin, bütünleşik (integral) süreçler altında tanımlandığı görülmektedir [3]. Bütünleşik (integral) süreçler, RTCA/DO-178C dokümanında, yazılım yaşamdöngüsü süreçleri ile bu süreçlere ait çıktıların kontrolünü ve doğruluğunu garanti altına almaya yönelik süreçler olarak tanımlanmaktadırlar [3]. Yazılım doğrulama süreci, yazılım kalite güvence süreci, sertifikasyon irtibat süreci ve yazılım konfigürasyon yönetimi süreçleri bütünleşik (integral) süreç olarak sınıflandırılmıştır. Bütünleşik(integral) süreçler, projenin başlangıcında yer alan planlama sürecinden itibaren uygulanmaya başlanıp, diğer yazılım yaşamdöngüsü süreçleri ile paralel olarak projenin yaşamdöngüsü boyunca yürütülmektedir.
RTCA/DO-178C dokümanı, konfigürasyon yönetimi sürecine yönelik aktivitelerin yazılım yaşamdöngüsü çıktılarının doğasına ve geliştirilen yazılımın kritiklik seviyesine göre hangi detay ve titizlikte uygulanacağına yönelik sınıflandırma yapabilmek için “veri (data) kontrol kategorileri” kavramını kullanmaktadır. RTCA/DO-178C dokümanında, iki adet veri kontrol kategorisi tanımlanmıştır [3]:
Kontrol kategori 1 (CC1)
Kontrol kategori 2 (CC2)
RTCA/DO-178C dokümanı bölüm 7.3 “Veri Kontrol Kategorileri (Data Control Categories)” başlığı altında yer alan Tablo 7.1’de, her bir kontrol kategorisi için uygulanması gereken konfigürasyon kontrol yönetim aktivitelerinin listelendiği görülmektedir. Kontrol kategori 1 (CC1) olarak sınıflandırılan çıktılar için RTCA/DO-178C dokümanında tanımlı tüm konfigürasyon kontrol yönetim aktivitelerinin uygulanması gerekirken, kontrol kategori 2 (CC2) olarak sınıflandırılan çıktılarda konfigürasyon kontrol yönetim aktivitelerinin bir alt kümesinin uygulanması yeterlidir [3]. Örneğin kontrol kategori 1 (CC1) olarak sınıflandırılan çıktılar için problem raporlama sürecinin işletilmesi beklenilirken, kontrol kategori 2 (CC2) olarak sınıflandırılan çıktılarda problem raporlama sürecinin işletilmesine gerek yoktur.
Kontrol kategori 1 (CC1) olarak sınıflandırılan çıktılara, tüm yazılım konfigürasyon kontrol aktiviteleri uygulandığı için, yazılım sertifikasyon sürecinde kilit öneme sahip çıktılar kontrol kategori 1 (CC1) olarak sınıflandırılmaktadır. Örneğin olası bir kaza durumunda, soruşturma esnasında ihtiyaç duyulabilecek olan yazılım yaşamdöngüsü çıktıları genelde kontrol kategori 1 (CC1) olarak sınıflandırılmaktadır. Benzer şekilde, yazılımların kritiklik seviyesi arttıkça, daha fazla sayıda çıktı kontrol kategori 1 (CC1) olarak sınıflandırılmaktadır. RTCA/DO-178C dokümanında yer alan belli başlı yazılım yaşamdöngüsü çıktılarının yazılım kritiklik seviyelerine göre ait oldukları veri kontrol kategorileri aşağıdaki tabloda verilmiştir.
Tablo incelendiğinde, RTCA/DO-178C dokümanı bölüm 9.3’te sertifikasyon otoritesine teslim edilmesi gereken asgari yazılım yaşamdöngüsü çıktıları arasında yer alan, “Plan for software aspects of certification (PSAC)”, “Software Accomplishment Summary (SAS)” ve “Software Configuration Index (SCI)” dokümanlarının tüm yazılım kritiklik seviyeleri için kontrol kategori 1 (CC1) olarak sınıflandırıldığı görülmektedir. Kritiklik seviyesi A ve B olan yazılımlar için, veri kontrol kategori sınıflandırmaları birebir aynı olacak şekilde tanımlanmıştır. Seviye C ve D olan yazılımlarda ise veri kontrol kategori sınıflandırmaları farklıdır. Bu bilgiden hareketle, RTCA/DO-178C uyumlu olarak geliştirilecek olan projelerin, planlama aşamalarında, yazılım konfigürasyon yönetimi faaliyetlerine yönelik işgücü planlaması yapılırken, seviye A ve B olan projelerde, seviye C ve D olan projelere oranla daha fazla işgücü planlaması yapılması gerektiği söylenebilir. Tabloda yazılım kalite güvence kayıtları (örneğin gözden geçirme kayıtları, iç denetim raporları gibi) ile yazılım konfigürasyon yönetim kayıtları (örneğin problem raporları, konfigürasyon kontrol kurulu tutanakları gibi) bütün kritiklik seviyeleri için kontrol kategori 2 olarak sınıflandırıldığı görülmektedir. Buradaki durum bu çıktıların doğası gereği kayıt oldukları için, versiyonlama veya değişiklik isteği ile güncelleme gibi durumların söz konusu olmamasından kaynaklanmaktadır. Örneğin; konfigürasyon kontrol kurulu tutanakları kayıt niteliğinde olduğu için, sürüm verilebilecek veya değişiklik isteği açılarak güncellenebilecek bir çıktı değildir. Bu sebeple kontrol kategori 2 (CC 2) olarak sınıflandırılmaktadır.
RTCA/ DO-178C dokümanında tanımlanmış iki farklı yazılım yaşamdöngüsü çıktısının, tek bir çıktı olarak üretildiği durumlarda, nihai çıktının veri kontrol kategorisinin bir araya getirilen çıktılardan hangisinin kontrol kategorisi daha yüksek ise o olacak şekilde belirlenmesi gerekmektedir [4]. Örneğin; kritiklik seviyesi D olan bir projede, “Software Lifecycle Environment Configuration Index” ile “Software Configuration Index” dokümanlarını ayrı ayrı çıkarmak yerine, iki çıktının RTCA/DO-178C gereği içermesi gereken tüm bilgileri içeren “Software Lifecycle Environment Configuration Index” isimli tek bir çıktı üretildiği durumda, bu çıktının konfigürasyon kategorisinin, kontrol kategori 1 (CC1) olarak belirlenmesi ve konfigürasyon kontrol faaliyetlerinin buna göre yapılması gerekmektedir.
Son olarak, RTCA/DO-178C dokümanında kontrol kategori 2 olarak sınıflandırılan çıktıları, geliştirme ekipleri dilerlerse kontrol kategori 1 (CC1) olarak tanımlayabilir veya bu çıktılara kontrol kategori 1 (CC1)’de tanımlı olan aktiviteleri uygulayabilir. Bazı durumlarda yürütülmekte olan projenin sözleşmesi de bu durumu mecbur kılabilir. Örneğin kritiklik seviyesi C olan bir projede, proje sözleşmesi gereği, yazılım kalite planının müşteri onayı alınarak yürürlüğe girmesi gerekiyor olsun. RTCA/ DO-178C dokümanında yazılım kalite güvence planı seviye C olan projelerde kontrol kategori 2 olarak sınıflandırılmış olmasına rağmen, ilgili proje özelinde kontrol kategori 1 (CC 1) olarak sınıflandırılması mantıklı ve doğru olacaktır. Genel olarak müşteri onayı gereken dokümanların kontrol kategori 2 (CC 2) olarak sınıflandırılması yanlış bir yaklaşım olacaktır. Kontrol kategori 2 (CC 2) sınıfındaki dokümanlarda değişiklik isteği, problem raporu gibi konfigürasyon yönetim aktiviteleri mecburi olmadığı için, bu durum müşteri onayına konu olan dokümanlarda büyük olasılıkla sıkıntılara yol açacaktır.
Kaynaklar:
SAE ARP4754A, “Guidelines for Development of Civil Aircraft and Systems”, 2010.
Rierson, L., Developing Safety-Critical Software. CRC Press, Boca Raton (2013).
RTCA, DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA Inc., Washington D.C. (2011).
RTCA, DO-248C Supporting Information for DO-178C and DO-278A, RTCA Inc., Washington D.C. (2011).
Tesekkurler