DO-178C dokümanında problem raporları; yazılım ürünündeki problemleri, projede işletilen süreçler ile planlar ve standartlar arasındaki uyumsuzlukları ve yazılım yaşamdöngüsü çıktılarındaki eksiklikleri kayıt altına almak ve tanımlamak için oluşturulan kayıtlar olarak tanımlanmaktadır. Problem raporlarında aşağıdaki bilgilerin olması beklenilmektedir [1]:
Problemin hangi konfigürasyon parçasında ve/veya hangi yazılım yaşamdöngüsü süreç aktivitesinde tespit edildiği
Problemi gidermek için hangi konfigürasyon parçalarının güncellenmesi gerektiği veya hangi süreçlerde güncelleme yapılması gerektiği
Problemin net şekilde anlaşılabilmesini ve çözülebilmesini sağlayabilecek detayda tanımlanması. (Problem tanımının, problemin yol açabileceği potansiyel emniyet ve fonksiyonel etkilerin analizine olanak tanıyacak ayrıntıda olması gerekmektedir.)
Problemi çözmek için yapılması gerekli düzeltmenin tanımı
Sertifikasyon süreci sonunda, halen kapatılamamış ve açık durumda olan problem raporlarının (open problem reports – OPR), sertifikasyon otoritesine teslim edilmesi gereken “Yazılım Başarım Özeti (Software Accomplishment Summary-SAS)” dokümanında “Yazılım Durumu (Software Status)” başlığı altında listelenmesi beklenilmektedir. Bu noktada DO-178B standardının ilgili bölümüne bakıldığında, problem raporlarının özetinin ve varsa yol açtıkları fonksiyonel limitasyonların “Yazılım Başarım Özeti (Software Accomplishment Summary-SAS)” dokümanında olmasının beklenildiği görülmektedir [2]. DO-178C’de ise ilgili beklenti bir miktar daha genişletilmiştir. DO-178C dokümanında, her bir açık problem raporunun açıklamasının, getirdiği fonksiyonel limitasyonların, operasyonel kısıtlamaların ve emniyet üzerindeki olası olumsuz etkilerinin belirtilmesi beklenilmektedir [1]. Ayrıca DO-178C dokümanı, her bir açık hata raporunun neden kapatılamadığına ilişkin bir gerekçe sunulmasını ve probleme ilişkin yapılması gereken mitigasyonlar mevcut ise bunlara yönelik detayların verilmesini istemektedir.
“DO-248C Supporting Information for DO-178C and DO-278A” dokümanında “Açık Problem Raporlarının Değerlendirilmesi ve Sınıflandırılması (Assessment and Classification of Open Software Problems)” başlığı mevcuttur [3]. Bu başlık altında, sertifikasyon onayı aşamasında çok sayıda açık problem raporunun olmasının onay alınması açısından risk oluşturabileceğine dair bir uyarı da mevcuttur. Bunun temel nedeni, fazla sayıda açık problem raporunun yazılımın yeterli olgunlukta olmadığının ve yazılım geliştirilirken uygulanması gereken süreç teminatı yaklaşımının düzgün şekilde yürütülmediğinin bir göstergesi olmasıdır[4]. Başlık altında açık problem raporlarının sınıflandırılmasında kullanılabilecek örnek bir şema da verilmiştir.
29 Temmuz 2020 tarihinde EASA tarafından yayınlanan AMC 20-189 “The Management of Open Problem Reports (OPRs)” dokümanı ise, DO-248C’de yer alan sınıflandırmadan farklı bir sınıflandırmayı önermektedir. AMC 20-189 yazılım ve kompleks-elektronik donanım için ortak bir problem raporlama yönetim sistemi sunmaktadır. AMC 20-189’un temel amaçlarından birisinin de yazılım ve kompleks-elektronik donanım için halihazırda farklı rehber dokümanlar tarafından önerilen farklı açık problem raporu yönetim usullerinde bir uyumluluk sağlamak olduğu doküman içerisinde vurgulanmaktadır.
AMC 20-189’da yer alan açık problem raporu sınıflandırmasında yer alan 4 ana sınıf aşağıdaki gibidir [5]:
Önemli (significant): Ürün, sistem veya ekipman seviyesinde; Ölümcül (Catastrophic) / Tehlikeli (Hazardous) veya Major (Major) hata durumlarına yol açan veya açabilecek olan açık problem raporları bu sınıfa girmektedir.
Fonksiyonel (Functional): Ürün, sistem veya ekipman seviyesindeki fonksiyonlar üzerinde etkisi olan problem raporları bu sınıfa girmektedir.
Süreç (Process): Emniyet ve fonksiyonel açısından potansiyel etkisi olmayan süreçsel uyumsuzluk ve eksiklikler bu sınıfa girmektedir.
Yaşamdöngüsü Verisi (Life-cycle data): Yazılım yaşamdöngüsü esnasında üretilen verilerle ilgili olan ancak süreçsel uyumsuzluk ve eksiklik kaynaklı olmayan açık problem raporları bu sınıfa girmektedir.
AMC 20-189’da açık problem raporu (OPR) sınıflandırmasında dokümanda yer alan ve yukarıda listelenmiş olan 4 sınıfın asgari olarak bulunması gerektiği belirtilmektedir. Bu 4 sınıfa ek olarak, ihtiyaç halinde alt sınıfların veya ek sınıfların tanımlanabileceği bilgisi mevcuttur. Dolayısıyla, projeler kendi ihtiyaçları özelinde plan dokümanlarında gerekli bilgileri vermek koşuluyla yeni sınıflar tanımlayabilirler. Açık problem raporlarının (OPR) sınıflandırılması esnasında, her bir açık problem raporunun sadece bir sınıfa girecek şekilde sınıflandırılması gerekmektedir. Örneğin bir açık problem raporu, hem “Önemli (significant)” hem de “Süreç (Process)” olacak şekilde sınıflandırılmamalıdır. Böyle bir durum oluşması halinde, AMC 20-189 en yüksek önem düzeyine sahip sınıfın seçilmesi gerektiğini vurgulamaktadır. Önem sıralaması, en yüksek önem düzeyinden en düşük önem düzeyine olacak şekilde aşağıdaki gibidir [5]:
Önemli (significant)
Fonksiyonel (Functional)
Süreç (Process)
Yaşamdöngüsü Verisi (Life-cycle data)
Proje özelinde tanımlanmış ek sınıflar
“Önemli (Significant)” olarak sınıflandırılmış olan açık problem raporlarına yönelik yeterli mitigasyon veya problemin emniyet üzerindeki etkilerinin kabul edilebilir seviyede olduğuna dair gerekçelendirme yapılmamışsa, sertifikasyon onayı öncesinde çözülmesi gerekmektedir. Sistem seviyesi, yazılım seviyesi ve donanım seviyesi açık problem raporlarının, sertifikasyon otoritesi tarafından talep edilmesi durumunda, bir rapor şeklinde otoriteye sunulması gerekmektedir. Bu raporlama esnasında açık problem raporunun sınıfına göre sunulması gereken asgari bilgi setleri AMC 20-189’da ayrıntılı şekilde açıklanmaktadır.
“DO-248C Supporting Information for DO-178C and DO-278A” dokümanında verilen Açık Problem Raporları Sınıflandırılma şeması ile AMC 20-189'da verilen sınıflandırmanın eşleştirilmiş hali aşağıdaki tablodaki gibidir.
AMC 20-189'un uygulanması esnasında yardımcı olarak kullanılabilecek FAA tarafından yayınlanmış "AC 00-71 - Best Practices for Management of Open Problem Reports (OPRs)" dokümanı mevcuttur. Bu dokümanda problem raporlarının yazılım yaşam döngüsü esnasında tespit edildikten sonra mümkün olduğunca erken aşamada sınıflandırılmasının yapılması tavsiye edilmektedir. Ayrıca sınıflandırma esnasında problem raporunun ilgili olduğu disiplinden(test pilotu, emniyet mühendisleri gibi) de temsilcilerin olması gerektiğine yönelik vurgu mevcuttur [5].
Projelerin planlama aşamalarında, AMC 20-189 rehber alınarak açık problem raporlarının ne şekilde yönetileceğinin kurgulanması ve planlarda yeterli detayda anlatılması gerekmektedir. Bu işlem yapılırken AC 00-71 gibi yardımcı dokümanlardaki bilgilerin de kullanılması yararlı olacaktır. Ayrıca AMC 20-189 gerek sistem seviyesi problemlerin gerekse yazılım-donanım seviyesi problemlerin yönetim ve sınıflandırılmasına yönelik bilgiler içerdiği için, sistem ekipleri tarafından da kullanılması gerekmektedir. Projelerin sertifikasyon onayı sürecinde, takvimsel baskılardan ötürü, çok sayıda açık problem raporu ile başvuru yapmanın, sertifikasyon onayı alınamaması ve daha ciddi takvimsel risklere yol açabileceği de hiçbir zaman akıldan çıkarılmamalıdır.
Kaynaklar:
RTCA, “DO-178C Software Considerations in Airborne Systems and Equipment Certification”, 2011.
RTCA, “DO-178B Software Considerations in Airborne Systems and Equipment Certification”, 1992.
RTCA, “DO-248C Supporting Information for DO-178C and DO-278A”, 2011.
Leanna Rierson, “Developing Safety-Critical Software”, CRC Press, 1st Edition, 2013.
EASA, AMC 20-189, “The Management of Open Problem Reports (OPRs)”, 2020.
FAA, AC 00-71 "Best Practices for Management of Open Problem Reports (OPRs)", 2022.
Commentaires