DO-178B Sertifikasyonuna Uygun Yazılım Geliştirme Software
Transkript
DO-178B Sertifikasyonuna Uygun Yazılım Geliştirme Software
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul) DO-178B Sertifikasyonuna Uygun Yazılım Geliştirme Software Development Compatible with DO-178B Certification Yusuf İbrahim ÖZKÖK SST-MD Yazılım Mühendisliği Müdürlüğü ASELSAN A.Ş., Ankara Serkan CEYLAN SST-MD Yazılım Mühendisliği Müdürlüğü ASELSAN A.Ş., Ankara [email protected] [email protected] Özet Yazılım ürünlerinin tekrarlanabilir ve ölçülebilir bir kalite seviyesinde geliştirilmesi ve üretilebilmesi için çeşitli standartlar ve bu standartların kullandığı yazılım yaşam döngüsü süreçleri tanımlanmıştır. Yazılım geliştiren kurumlar ürünlerini belli bir kalite seviyesinde üretmek ve bunu göstermek için bir yazılım geliştirme standardı kullanırlar veya bir yazılım yaşam döngüsü süreci takip ederler. Diğer taraftan üretilen yazılım ürünü önemli bir sistemin parçası olacaksa veya insan hayatını etkileyecek nitelikte ise bu durumda ulusal veya uluslar arası kuruluşlar tarafından bu tür yazılımların geliştirilme sürecinin uygun standartlarda olması istenir. Buna örnek olarak Sivil hava araçları için üretilen yazılımların DO-178B standardına uyma zorunluluğu vardır. Bu makalede DO-178B standardı genel hatları ile tanıtıldıktan sonra özellikle belli bir sürece uygun yazılım geliştiren bir şirketin bu standarda geçerken takip edebileceği yollar, karşılaşabileceği zorluklar ve dikkat etmesi gereken konular deneysel bilgilere dayanılarak anlatılmıştır. Abstract In order to develop and produce software products at a quotable and measurable quality level, various standards and software life cycle processes those use these various standards are defined. Software developing corporations use a software development standard or follow a software life cycle process, in order to produce and show their products at a certain quality level. On the other hand, if the produced software product will be a part of an important system or may affect the life of human being then at this circumstance for the national or international corporations requests to obey a standard for such software products. Such as the software produced for the civilian air vehicles have the obligation to meet the objectives defined by DO-178B. In this article after DO-178B Standard is explained roughly, especially for the companies which follow a certain process in software development, the path to follow when switching to this standard, the difficulties may be met and the issues to be taken in account are explained based on experimental data. 1. Giriş GATM (Global Avionics Traffic Management) anlaşmasına göre tüm sivil hava araçları FAA (Federal Avionics Agency) onayına tabidir. Yazılımlar için FAA onayı, DO-178B dokümanına uygunluk anlamına gelmektedir. Bunun yanında günümüzde askeri hava ve uzay araçlarında, nükleer santrallerde ve hatta deniz araçlarında, ya da genelleştirirsek, emniyet kritik sistem yazılımlarında yazılımların sistem emniyetini bozmamasının temini için DO-178B uyumluluğu bir sözleşme maddesi olabilmektedir. Bu makalede öncelikle DO-178B dokümanı tanıtılacaktır. Bu bölüm genel bir tanıtım niteliğinde olacaktır. Bir makaleye sığmayacak kadar geniş olan bu konunun detaylarına hakim olabilmek için standardın [1] kendisi incelenmelidir. Makalenin ikinci bölümünde ASELSAN-SST (Savunma Sistem Teknolojileri) grubunda yazılım geliştirme süreçlerinin DO-178B karşısında değerlendirilmesi çalışması sonucunda ortaya çıkan tespitler aktarılacaktır. Kurumsallaşmış bir yapıda standart süreçlere uygun yazılım geliştiren kuruluşların bu dokümanda belirtilen hedeflerden çok uzak olmadıkları söylenebilir. Yazılımları belli bir sürecin çıktısı olmayan dokümantasyon kültürü yerleşmemiş firmaların, yazılımlarının uçuşa elverişlilik sertifikasyonuna sahip olabilmesi için ise, bu doküman rehberliğinde yeniden yapılanmaya gitmeleri gerekebilir. Referans olması açısından bu iki ana tespit karşısında ASELSAN’ın durumu ilk sınıfa girmektedir. Ortaya konacak tespitler de bu yönde olacaktır. Son olarak uçuşa elverişlilik sertifikasyonun ne anlama geldiği DO-178B’nin buradaki yeri ve sertifikasyon tiplerinden bahsedilecektir. YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul) 2. DO-178B Tanımı ve İçeriği DO-178, RTCA (Radio Technical Commision For Aeronautics) bünyesindeki özel bir heyet (SC-167) tarafından yazılımların uçuşa elverişlilik gereklerini karşılamayı sağlayan ve endüstriden geniş kabul görmüş bir rehber olması hedefi ile 1982’nin ilk çeyreğinde hazırlanmış bir dokümandır. Bir rehber doküman olarak hazırlanan DO-178, FAA’in referans alması ile bir standart niteliği kazanmıştır. Zaman içinde yazılım alanındaki gelişmelere paralel olarak ve edinilen geri beslemeler ile bu doküman da güncellenmektedir. 1988’de RTCA bu dokümanın ikinci sürümünü DO-178A adıyla, 1992 Aralık ayında da halen kullanılan DO-178B’yi [1] yayınlamıştır. Bir sonraki sürümün DO-178C adı ile 2009 yılı içinde çıkması beklenmektedir. DO-178’in idamesi RTCA ve Avrupa’daki EUROCAE (European Organization for Civil Aviation Equipment) WG-12 (Work Group) örgütlenmesi ile beraber yürütülmektedir. Bu çalışmanın ana amaçları şu şekilde belirlenmiştir [1]; • Yazılım yaşam döngüsü süreçleri için takip edilecek hedeflerin ortaya konması • Bu hedeflere ulaşılabilmek için gerekli faaliyetlerin tanımlanması ve tasarım yaklaşımlarının belirlenmesi • Hedeflerin tam olarak karşılandığının gösterilebilmesi için delillerin tanımlanması. Bu dokümanda hava araçlarındaki sistemlerde kullanılmak üzere geliştirilen yazılım ürünlerinin uçuşa elverişlilik sertifikasyonu açısından uygunluğu incelenir. Bir bütünlük arz eden sertifikasyon sürecinin anlaşılabilmesi için sistem yaşam döngüsü ile yazılım yaşam döngüsü arasındaki ilişki de inceleme alanına dahil edilmiştir. Bu doküman kuruluşların organizasyon yapısı, altyüklenici gibi firmalarla olan ilişkileri ya da çalışan personelinin yetkinlik durumu ve eğitim durumu gibi konularla ilgilenmez. Diğer taraftan geliştirilen sistemlerin çalışma durumları, bu sistemlerde kullanılan teknolojiler, yazılım kodlama teknikleri, tasarım teknikleri gibi konularla da ilgilenmez. Her kuruluşun kendine özgü iş yapış tarzı, kendi doküman şablonları veya kullandığı standartlar olabilir. Uçuşa elverişlilik açısından DO-178B dokümanında belirtilen hedeflerin karşılanıyor olması yeter gerektir. Bu hedefler içinde birçok detaylar olmasına karşın işin özü açısından neyin nasıl yapılacağının pek bir önemi yoktur. Bunun yerine ortaya konan hedeflere uygun ve içeriği dokümanda tespit edildiği şekilde neyin nasıl yapılacağının planlanıyor olmasının ve tüm süreç boyunca bu planlara sadık kalındığının gösterilmesinin asıl temeli oluşturduğu söylenebilir. Bu dokümanın içeriği ile ilgili bir bakışta bilgi edinmemizi sağlayacak DO-178B dokümanı içeriğinin bir haritası Şekil 1’de verilmiştir. Şekil 1: DO-178B dokümanı haritası 2.1. Emniyet Seviyeleri Uçuşa elverişlilik sertifikasyonunda sistemler beş emniyet seviyesine ayrılmıştır. Bu seviyeler, sistemde oluşacak bir hatanın uçağın uçuş emniyetine getireceği etkiye göre belirlenmektedir. Sistemdeki bir hatanın oluşturacağı etkilere göre emniyet seviyelerinin tanımlaması aşağıdaki tabloda verilmiştir. Bir not olarak; bazı kaynaklarda “emniyet seviyesi”, “güvence seviyesi” olarak da isimlendirilebilmektedir. Tablo 1: Emniyet seviyeleri tanımları Emniyet Seviyesi A B C D Hatanın Oluşturacağı Etki “Hatanın …” • Güvenli uçuşu ve inişi engellemesi. Ölüme yol açması. Uçağı düşürmesi! • Fonksiyonel yetenekleri veya emniyet paylarını ciddi şekilde azaltması. • Uçuş mürettebatını fiziksel olarak etkilemesi veya iş yapamayacak şekilde iş yükünü arttırması. • Yolcuların ciddi yaralanmasına veya ölümcül yaralanmalarına sebebiyet vermesi • Fonksiyonel yetenekleri veya emniyet paylarını belirgin olarak azaltması. • Mürettebatın iş yükünü belirgin olarak arttırması. • Yolcuların rahatsızlanmasına veya yaralanmasına sebebiyet vermesi • Fonksiyonel yetenekleri veya emniyet YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul) DO-178B dokümanında bu emniyet seviyelerine göre yazılım yaşam döngüsünde karşılanması beklenen hedefler artımsal olarak belirlenmiştir. Bu durum sürecin, farklı emniyet seviyelerinde farklı sıkılık derecelerine sahip olması sonucunu doğurmaktadır. Böylece çok kritik olan bir iniş kontrol yazılımına harcanacak çaba ile bir yolcu bilgilendirme sistemine harcanacak çaba aynı olmayacaktır. Dolayısıyla yazılımların kritiklik seviyesine göre ödenecek bedel de seviyelendirilmiş olacaktır. Buradan çıkarılacak en önemli sonuç ise uçuşa elverişlilik sertifikasyonunda sistemlerin emniyet seviyelerinin belirlenmesinin doğrudan sistem maliyetine ve kullanım alanına yansıyacağının bilinmesidir. Çeşitli sistemlerde kullanılabilecek yazılımlar açısından ise düşük bir seviye belirlemek yazılımın kullanım alanını daraltırken, yüksek seviye belirlemek ise onaylama işlemini gereksiz yere zorlaştıracak ve harcanacak iş gücünü ve dolayısıyla maliyeti çok fazla arttıracaktır. Özet olarak DO-178B’de emniyet seviyesi yazılımı geliştirmek için harcanacak çaba ve parayı doğrudan etkileyen bir parametredir. Emniyet seviyelerinin isimlendirilmesi ve her seviyeye karşılık yerine getirilmesi gereken hedef maddesi sayısı Tablo 2’de verilmiştir. Tablo 2: Emniyet seviyelerine göre hedef sayısı Hata Sınıfı isimlendirmesi Ölümcül (Catastrophic) Tehlikeli (Hazardous) Büyük (Major) Küçük (Minor) Etkisiz (No Effect) Emniyet Seviyesi A Hedef Sayısı 66 B 65 C D E 57 28 0 Bu tablodaki hedef maddesi sayıları sadece nitelik ifade etmektedir. Nicelik olarak bir madde bazen çok fazla iş gücüne karşılık geliyor olabilir. Örneğin B seviyesinden A seviyesine geçerken tabloda bir tane daha fazla hedefin karşılanması yetiyormuş gibi görünmekle beraber, MC/DC (Modified Condition / Decision Coverage) yapısal kapsama analizine karşılık gelen bu maddenin yerine getirilmesi için çok ciddi bir ek işçilik harcanması gerekmektedir. Emniyet seviyelerine göre toplam proje bütçesine yansıyacak ek maliyet ilişkisi Şekil 2’de gösterilmiştir. Bu grafik gerekli eğitim ve danışmanlıklar alındığı varsayılarak ve bir danışmanlık firmasının verilerine dayanılarak üretilmiştir. Bu şartlarda DO-178B’nin getireceği ek yükün %10 ile %40 arasında olacağı belirtilmektedir. Fakat Endüstri ortalamasının %75 ile %150 olduğu istatistiksel olarak ölçülmüştür. [2] Emniyet seviyelerine göre maliyet artışı Toplam proje bütçesine gelen ek yük (%) E paylarını hafif olarak etkilemesi. • Mürettebatın iş yükünü hafifçe arttırması. Mesela rutin işlerde bir sapma meydana getirebilir. • Yolcuların memnuniyetsizliğine sebebiyet vermesi. • Hiçbir etki oluşturmaması. 45 40 35 30 25 20 15 10 5 0 E D C B A Em niyet Seviyeleri Şekil 2: Emniyet seviyelerine göre maliyet artışı Emniyet seviyeleri sistem seviyesinde yapılan ve Sistem Emniyet Değerlendirmesi (SED, ing: System Safety Assessment, SSA) olarak isimlendirilen bir çalışma sonucunda belirlenir. Bu çalışma yazılım hatalarının sistem hatalarına katkısını belirlemeye çalışır. SED ile FTA (Fault Tree Analysis), FMCEA (Failure Modes, Effects and Criticality Analysis) gibi yöntemlerle oluşabilecek hataların sonuçları analiz edilir ve bunun sonucunda yazılım için emniyet gerekleri türetilir. Bu çalışmanın önemini vurgulamak için şöyle bir örnek verebiliriz; yazılımların doğrulanması ve hatasız olması yazılım gerekleri anlamında değer taşır. Fakat oluşacak özel bir durumda yazılım gereklerinin sebep olacağı bazı kısıtlar sistemin emniyetsiz bir duruma girmesine yol açabilir. Böyle bir durumda yazılım sıfır hatayla çalışsa bile sistem emniyeti ortadan kalkabilir. DO-178B’de her ne kadar neyin nasıl yapılacağına karışılmasa da sistem emniyetini sağlamaya yönelik bazı öneriler de verilmiştir. Bunlar hafıza bölümleme, çoklu versiyon-farklı yazılımlar, sistemde emniyet izleme özelliğinin bulunması tarzında önerilerdir [1]. 2.1. Yazılım Yaşam Döngüsü Süreçleri DO-178B belli bir yazılım yaşam döngüsü modeli öne sürmek yerine çoğu modelde bulunan süreçleri ayrık olarak detaylı bir şekilde anlatmıştır. Bu süreçler uygun bir şekilde organize edilerek şelale modeli, sarmal model v.s. gibi yazılım yaşam döngüsü benzeklerine uygulanabilir. Fakat bu yapıyı artımsal şelale modeli YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul) dışındaki benzekler için uygulamanın gereksiz bir zorlama olacağı söylenebilir. Daha açık bir ifade ile bu rehber dokümanda anlatılan süreçlere en uygun benzek artımsal şelale modelidir. DO-178B’de şu süreçler anlatılmıştır (bknz. Şekil 3); • 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önetim süreci • Yazılım kalite güvencesi süreci • Sertifikasyon makamı irtibat süreci Bu liste son madde hariç yazılım mühendisleri için çok bilinen yaşam döngüsü süreçleri listesidir. Son madde ise uçuşa elverişlilik sertifikasyonu söz konusu olduğunda doğal olarak ortaya çıkan bir süreçtir. DO178B’de her süreç, o sürecin amaçları, o süreçte yapılması gereken çalışmalar, sürecin çıktıları ve sürecin tamamlanma ölçütleri ana başlıkları altında ayrıntılı bir şekilde anlatılmıştır. Hem sertifikasyon makamı ve hem de bu standardın ruhu açısından planlama ve doğrulama süreçlerinin diğerlerinden ayrılan özel bir yeri vardır. DO-178B’de Şekil 3’teki süreç haritasının ürünleri olarak Tablo 3’teki çıktılar tanımlanmıştır. Bu listede “Doküman” olarak sınıflandırılan çıktılar her seviye için üretilmesi gereken çıktılardır. Diğer çıktılar üretilip üretilmeyeceği ise emniyet seviyesine bağılıdır. Ayrıca emniyet seviyesine bağlı olarak bu çıktıları içerikleri de değişebilmektedir. DO-178B dokümanında tüm çıktılar ve içerikleri detaylı olarak anlatılmıştır. Tablo 3 DO-178B çıktıları listesi Kısaltma PSAC SDP SVP SCMP SQAP SRS Sistem Gereksinimleri Planlama Süreci Standartlar SDS SCS Geliştirme Süreci Standartlar, ortam tanımı Doğrulama Yöntemleri SRD SDD Gereksinimler, Tasarım ve Kod Doğrulama Sonuçları SVCP Tamamlayıcı Süreçler Sertifikasyon Süreci Konfigürasyon Yönetim Süreci Doğrulama Süreci Test SVR SECI Kalite Güvencesi Süreci SCI - Şekil 3: DO-178B Süreç Haritası [3] Sertifikasyon otoriteleri açısından en önemli konu planlamadır. İlk olarak planlar incelenir ve sonrasında bu planlara uygunluk kontrol edilir. Doğrulama sürecinden çoğu zaman sadece yazılımın gereklere uygunluğunun doğrulanması ve yazılım test süreçleri anlaşılır. Fakat burada doğrulama süreci yazılım testinin yanı sıra tüm yapılanların planlara ve DO178B hedeflerine uygunluğunun doğrulanması anlamına da gelmektedir. Ayrıca doğrulama süreci içerisinde testlere ilaveten yapılması gereken test kapsama analizi de DO-178B’nin ayırt edici bir özelliği olarak belirtilebilir. SAS Doküman Adı Tip Plan for Software Aspects of Doküma Certification n Doküma Software Development Plan n Doküma Software Verification Plan n Software Configuration Doküma Management Plan n Doküma Software Quality Assurance Plan n Software Requirements Standart Standards Software Design Standards Standart Software Code Standards Standart Doküma Software Requirements Data n Doküma Software Design Description n Source Code Kod Executable Object Code Binary Software Verification Cases and Doküma Procedures n Software Verification Results Kayıt Software Life Cycle Environment Doküma Configuration Index n Doküma Software Configuration Index n Problem Reports Kayıtlar Software Configuration Kayıt Management Records Software Quality Assurance Kayıt Records Software Accomplishment Doküma Summary n 3. Kendi süreçlerine sahip kurumsallaşmış bir şirkette DO-178B’nin uygulanması İlk defa DO-178B standardına uygun yazılım geliştirecek, AQAP-160, CMM gibi standartları uygulayan şirketler bazı zorluklarla ve uyum sorunları ile karşılaşabilirler. Bunun da ötesinde DO-178B’nin YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul) uygulanmasının getireceği ek iş gücü olması gerekenin çok daha üstünde gerçekleşebilir. En kötüsü ise proje sonunda sertifikasyon sürecinde sorunların çıkması olacaktır ki bu tüm sürecin tekrarlanmasını gerektirebilir. Bu tip riskleri minimize etmek için konunun başta görünmeyen ve ancak tecrübe ile kazanılabilecek yanlarının bilinmesi gerekir. Bu bölümde bizim edindiğimiz deneyimler ve karşılaştığımız sorunlarla ilgili bazı bilgiler aktarılmaya çalışılacaktır. beraberinde sonraki uygulanmalıdır. Uçuşa elverişlilik sertifikasyonuna yönelik yazılım geliştirmek; sadece bu işin standardı olan DO-178B dokümanını okuyup anlamak ve uygulamak şeklinde anlaşılmamalıdır. Bu dokümanda tariflenen hedeflerin karşılanabilmesi için belli bir iş yapış mantığının yerleştirilmesi ve bilgi birikimi gerekmektedir. Bu bilgi birikiminden, kurumun kullandığı doküman şablonlarından, kullanılan otomatik test araçlarına yazılım geliştirme yöntemlerine kadar aslında çok uzun sürede kazanılabilecek bir kurumsal bilgi dağarcığı (know-how) anlaşılmalıdır. Şu unutulmamalıdır ki; süreç eşittir doküman demek değildir! DER kiralamak: DER, sertifikasyon makamının yetkilendirdiği ve onay yetkisi olan süreci tetkik edip geri besleme vererek gidişatı kontrol edebilecek bağımsız bir uzman kişidir. Uçuşa elverişlilik sertifikasyonu istenen projelerde, projeye atanmış bir DER bulunması zaten bir zorunluluktur. Sertifikasyonun şart olmadığı fakat sertifikalandırılabilir nitelikte olması istenen bir DO178B projesinde de projenin başlarında bir DER kiralayarak projenin her aşamasında onay alınarak da devam edilebilir. Böylece proje sonunda projemiz otomatik olarak onaylanmış olacaktır. Fakat sertifikasyonun şart olmadığı sadece bir kalite standardı amaçlanan ve özellikle gizlilik arz eden askeri projelerde bu yöntem pek tercih edilmez. Alt bölümlerde yazılım şirketlerinin mevcut bilgi dağarcığına en kısa sürede DO-178B uyumluluğu kazandırmak için uygulanabilecek seçenekler dikkat edilmesi gereken konular ve en sonunda da gerçek bir durum çalışması verilmiştir. 3.1. Kurumsal bilgi dağarcığının uyumlandırılması Kurumsal bilgi dağarcığını en hızlı şekilde bu standarda uyumlandırmak için tespit ettiğimiz bazı yollar şunlardır; • Eğitim almak, • Danışmanlık hizmeti almak, • DER (Designated Engineering Representative) kiralamak, • Sertifikasyon gereği olan bir projenin parçası olmak. Eğitim: Dünya çapında bu konuda uzmanlaşmış üç dört büyük kuruluştan birinden 1 haftalık DO-178B eğitimi alınabilir. Bu sayede sertifikasyona tabi bir projedeki insan kaynağına hızlıca DO-178B adaptasyonu sağlanabilir. Bu eğitimler dâhilinde çoğu zaman süreç çıktılarının oluşturulması için kullanılabilecek doküman şablonları kontrol listeleri gibi çok değerli kaynaklar da verilmektedir. Bu seçeneğin bir dezavantajı bir haftalık yoğun bir eğitimde uygulama alışkanlıklarının değiştirilemeyeceğidir. Bu yüzden bizim önerimiz bu seçeneğin tek başına yeterli olacağı düşünülmemeli ve üç seçenekten biri de Danışmanlık hizmeti almak: Eğitim veren bu belli başlı kuruluşlar aynı zamanda danışmanlık hizmeti de sunmaktadırlar. Danışmanlık belli aralıklarla ayrık zamanlarda ortaya çıkan sorunların giderilmesi amacıyla olabileceği gibi tüm proje süresince projenin gidişatının sürece uygunluğunun takibi şeklinde de olabilir. Sertifikasyon gereği olan bir projede alt yüklenici olmak: Böyle bir imkân var ise ilk defa DO-178B uyumlu yazılım geliştirecek bir firma için en uygun ve verimli seçenek bu olabilir. Bu durumda sürecin takibini büyük ölçüde üst yüklenici yapacak ve sizi gerektiği şekilde yönlendirecektir. Büyük ihtimalle üst yüklenici bir DER kiralamış veya danışmanlık hizmeti alıyor olacaktır. Bu imkânlardan alt yüklenici firma da yararlanabilecektir. Tüm süreç çıktıları üst yüklenici firma tarafından tekrar gözden geçirilecek ve bir bakıma sorumluluk da dağıtılmış olacaktır. 3.2. Sürecin sıkılığının emniyet seviyesine göre değişmesi DO-178B’de yazılımların emniyet seviyelerine göre sınıflandırıldığı, sürecin sıkılığının bu seviyelere göre değiştiği ve seviye azaldıkça karşılanması beklenen hedeflerin azaldığı akıldan çıkarılmamalıdır. Belli bir süreci uygulayan yazılım şirketleri tüm yazılım ürünlerini aynı süreçten geçirirler. DO-178B’de seviyelerin farkında olunmazsa bu mantığa takılıp gereksiz çalışmalar yapılabilir. Bu duruma düşmekten kaçınılmalıdır! 3.3. Dokümantasyon uyumlaması DO-178B’de tanımlı süreç çıktıları büyük ölçüde dünyada kabul görmüş yazılım geliştirme süreçleri çıktıları ile aynıdır. Bunun yanında DO-178B’ye özel YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul) bazı ek çıktılar olabilmektedir. Şirketimizin sürecinde olmayan ama DO-178B’de istenen çıktılar olabilir. Bu çıktıların tanımlanıp gerekli numaralandırmalarının yapılması konfigürasyon yönetimi sistemi içine alınması gerekmektedir. Diğer bir konu da doküman şablonlarıdır. DO-178B dokümanlar için belli bir şablon öngörmemektedir. Sadece her dokümanın içinde olması gereken konular listelenmiştir. Fakat sertifikasyon sürecinde sertifikasyon otoritelerinin önüne gelen dokümanların belli bir düzende olması daha açık bir ifade ile sertifikasyonu yapan kişilerin alışık oldukları yapıda olması sertifikasyon sürecini hızlandırması ve kolaylaştırması anlamında önemlidir. Bu nedenle doküman şablonlarının danışmanlık şirketlerinden veya başka kaynaklardan temin edilecek DO-178B uyumlu şablonlarla karşılaştırılması, gerekiyorsa güncellenmesi yerinde bir davranış olur. 3.4. Yazılım geliştirme ortamı ve araçlarında aranılan uyumluluk Her yazılım şirketinin, dahası her yazılımcının geliştirdiği yazılım tipine bağlı olarak kullandığı bir yazılım geliştirme ortamı ve araçları, kullandığı çeşitli yazılım kütüphaneleri vardır. Standart yazılım geliştirme süreçlerinde yazılımların üretilmesinde büyük katkısı/etkisi olan bu üçüncül kaynaklar pek sorgulanmaz. Fakat DO-178B standardında yazılım ürününü etkileyen her şey sertifikasyona tabidir, dolayısıyla bunların da onaylanması gerekir. Yazılım araçları iki sınıfa ayrılmıştır; yazılım geliştirme araçları, yazılım doğrulama araçları. • Yazılım geliştirme araçları: Çıktısı yazılımın bir parçası olan araçlar bu sınıfa girer. Örneğin tasarımdan otomatik kod üreten araçlar ya da derleyiciler. Eğer bu tip araçların ürettiği çıktı DO178B doğrulama yöntemlerine göre doğrulanmayacaksa bu aracın onaylı (qualified) bir araç olması gerekir. • Yazılım doğrulama araçları: Bu sınıftaki araçlar; çıktısı yazılımın bir parçası olmayan fakat süreci etkilediği için hataların tespitini engelleyebilecek araçlar olarak tarif edilmiştir. Örneğin test araçları, analiz araçları, statik kod analizi araçları. Eğer bu araçların ürettiği çıktılar DO-178B’ye göre doğrulanmadan kullanılmak isteniyorsa bu araçların onaylı olması gerekmektedir. DO-178B’ye göre yazılım yaşam döngüsü süreci içinde kullanılan bir aracın onaylanmasının gerekip gerekmediği aşağıdaki üç soruya verilen cevaplara göre belirlenebilir. 1. 2. 3. Bu araç yazılım ürünü içinde hatalar oluşturabilir veya mevcut bir hatanın tespit edilmesini önleyebilir mi? Bu aracın çıktısı DO-178B bölüm 6 altındaki doğrulama adımlarında doğrulanmayacak mı? Bu araç DO-178B süreçlerinde bir otomasyon ya da basitleştirme sağlıyor mu? Eğer bu üç soruya evet cevabı veriliyorsa bu aracın onaylı olması gerekmektedir. Yazılım araçları dışında yazılımımızda kullanacağımız kütüphanelerin ya da RAHAT (Rafta Hazır Ticari) ürünlerin de sertifikalı olması ya da bizim tarafımızdan DO-178B standartlarına uygun hale getirilmesi gerekmektedir. Bu durum kullanabileceğimiz hazır kütüphaneler için dünyada oluşmuş olan çok geniş bir yazılım arşivinden yararlanmamamıza ve sadece çok kısıtlı olan sertifiye edilmiş ürünlerle sınırlı kalmamıza neden olmaktadır. Bu kısıtlardan dolayı yazılım firmaları uzun süreler boyunca oluşturdukları kendi yazılım kütüphanelerini ve oluşturdukları yazılım geliştirme ortamlarını bir tarafa koyup yeni kaynaklar aramak ve yeni bir geliştirme ortamı oluşturmak zorunda kalabilirler ki bu durum hem maliyet hem de zaman açısından çok büyük bir engeldir. 3.5. Fark Analizi (Gap Analysis) Profesyonel olarak yazılım geliştiren her firmanın belli bir yazılım geliştirme süreci bulunmaktadır. Bu sürecin DO-178B’ye uygunlaştırılması için düzeltilmesi ve/veya eklenmesi gereken süreçlerin ve süreç çıktılarının belirlenmesine yönelik yapılan çalışmaya fark analizi (Gap Analysis) denir. Dünyada çeşitli danışmanlık şirketleri bu hizmeti vermektedir. Böyle bir fark analizi çalışması analizin yapılacağı kurumun süreçlerini iyi bilen bir uzmanın da çalışmaya dahil olması şartı ile 2-4 adam/hafta gibi bir sürede tamamlanabilmektedir. Bir danışmanlık firması önceki tecrübelerini analiz ederek CMM seviyelerine göre DO178B B seviyesi örtüşme oranlarını çıkartmıştır. Bu çalışmanın sonuçları Tablo 4 ve Tablo 5’de verilmiştir. [4] Tablo 4: CMM Seviyelerinin DO-178B B seviyesini Kapsama Oranı SEI CMM Seviyesi SEI CMM Level 1 Organization SEI CMM Level 2 Organization SEI CMM Level 3 Organization SEI CMM Level 4 Organization % Eksiklik %70 - %90 %50 - %75 %35 - %60 %25 - %40 YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul) SEI CMM Level 5 Organization Tablo 5: DO-178B Süreçlerinin Örtüşme Oranları (CMM-3 ten DO-178B B seviyesine) Sertifika Faaliyeti Eksiklik Oranı PSAC %80 QA Plan %20-30 CM Plan %10-20 Development Plan %40-50 Software Verification Plan %60-70 Safety Assesment %80-90 Requirements Definition %20-30 Design %10-15 Code %5-10 Functional Test %5-10 Structural Coverage Test %90-100 CM %10-30 QA %50 Tool Qualification %100 Checklists %30-50 Reviews %30-50 Audits %30-50 DER Liaison %100 Not: %0 eksiklik %100 örtüşme anlamına gelir. ASELSAN’da benzer bir çalışma danışmanlık alınmadan yapılmıştır. Bu çalışma sonucunda uyguladığımız sürecin DO-178B’ye karşılık geldiği seviye ortaya çıkartılmıştır. Fakat tam olarak bu seviyenin karşılanabilmesi için bazı doğal olarak yapılan fakat resmi olarak sürecimizde bulunmayan belgelendirilmemiş çalışmaların da disipline edilerek resmileştirilmesi ve tabi ki sertifikasyona özel ek doküman ve çalışmaların da sürecimize eklenmesi gerektiği ortaya çıkmıştır. Bunun yanında, bu seviyede istenmeyen fakat sürecimizde bulunan birçok ek faaliyetin de çıkartılması, gereksiz maliyet artışının önüne geçilmesi adına gereklidir. 3.6. Durum çalışması Hâlihazırda ASELSAN’da DO178-B seviye göre geliştirmekte olduğumuz bir projenin yöntem ile geliştirilmesi durumunda oluşan karşılaştırması gerçek veriler birim ile ifade Tablo 6’de verilmiştir. D/C ye standart maliyet edilerek Tablo 6: Gerçek bir maliyet karşılaştırması DO178-B D/C Seviyesine Göre Yazılım Geliştirme (birim) %20 - %35 Standart Yazılım Geliştirme (birim) Altyapı Giderleri Sertifikasyon Giderleri İşçilik Giderleri Toplam Gider 1960 710 4225 - 169 121 6354 831 DO178-B seviye D/C ye göre yazılım geliştirmedeki giderleri standart yazılım geliştirmede harcanan giderler ile karşılaştırdığımız durumda yaklaşık sekiz katlık bir fark oluştuğu görülmektedir. Fakat burada ilk defa DO-178B’ye geçişten kaynaklanan yatırım maliyetleri olduğu gözden kaçırılmamalıdır. DO178-B uyumlu yazılım geliştirme için kullanılan işletim sistemi, geliştirme ortamı ve test araçlarının özel olması nedeniyle maliyetlerinin standart ürünlere kıyasla çok daha pahalı olduğu görülmektedir. DO178B seviye D/C ye göre yazılım geliştirmede en büyük gideri sertifikasyon kaleminin oluşturduğu görülmektedir. Bu kalem kullanılan geliştirme ortamları, test yazılımları ve hazır kütüphanelerin sertifikasyon materyallerinin maliyetinden oluşmaktadır. İşçilik giderlerinin farklılığındaki en büyük etken ise geliştirilen yazılımın sertifikasyon gereklerini yerine getirmek için harcanan ek çabadır. 4. Sertifikasyon Süreci Bu bolümde uçuşa elverişlilik sertifikasyonunun neyi ifade ettiği ve yazılımın bu kavram içindeki yeri anlatılacaktır. DO-78B ile ilgili belgelerde bu kavram çoğu zaman karıştırılmakta veya hiç anlatılmamaktadır. Tek başına DO-178B sertifikasyonu diye bir şey yoktur. Sivil hava araçlarında uçuşa elverişlilik sertifikasyonu dâhilinde yazılım ürünlerinin sertifikasyonu sadece bir bölümü oluşturur. Sonuçta sertifikasyon denilince söz konusu olan donanım ve yazılımdan oluşan bir sistemin bütünüdür. Bir hava aracı veya sistem sertifikasyonu bir FAA projesi açılmasını takiben, FAA proje numarası alınması ile başlar. Önerilmemekle beraber FAA projesi açtırmadan da projenin herhangi bir aşamasında veya sonunda sertifikasyon için başvurulabilir. Bu durumda FAA’in önemli önerilerinden ve etkileşimden mahrum olarak geliştirilen proje’nin uygun görülmeme ihtimali yüksektir. Emniyet seviyesi ile orantılı olarak süreçler arası ilişkinin artması nedeniyle özellikle C seviyesinden sonra istenen ek gerekleri karşılamak birçok işin tekrarlanmasını gerektireceği için projenin toplam iş yüküne yakın bir iş yükü getirebilir. Bir FAA projesi şu üç sertifikasyon tipi için açılabilir. YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul) 1. 2. 3. TC (Type Certificate) STC (Supplemental Type Certificate) TSO (Technical Standard Order) TC bir hava aracının tamamının sertifikasyonu anlamına gelmektedir. Bu hava aracının üzerindeki bütün fabrikasyon birimler de bu TC’ye dâhildir. Hava aracına sonradan eklenecek cihazlar için ise STC olarak adlandırılan sertifikasyon uygulanır. STC, TC’ye bir ek gibi düşünülmelidir. Her STC sadece bir TC’ye ait olabilir. Yani bir hava aracı için geliştirilen bir cihaz başka bir hava aracına aynı STC ile takılamaz. Bunun için diğer hava aracının TC’si altında bir STC alınması gerekmektedir. Genel geçer birimler için TSO adı altında üçüncü bir sertifikasyon türü vardır. Her hava aracına ya da birden fazla hava aracına takılmak üzere geliştirilen cihazlar TSO’ya tabi olabilir. TC sadece hava aracı üreticilerinin başvurabileceği bir sertifikasyondur. STC’ye ise hava araçları için yeni birimler üreten nispeten küçük firmalar da başvurabilir. Fakat STC hangi TC için alınacaksa o hava aracına sahip bir firma ile önceden anlaşmış olmak gerekmektedir. Çünkü STC’nin ilgilendiği hava aracının cihazı üreten üretici tarafından ulaşılabilir olması şartı vardır. Tabii ki bu hava aracı satın alınarak ya da kiralanarak da bu şart sağlanabilir! TSO için ise önceden belirlenmiş sınıflandırmalar vardır. Üretilen cihaz daha önceden üretilen cihazlara göre belirlenmiş TSO sınıflandırmalarından birine giriyorsa, cihaz bu TSO ile sertifikalandırılabilir. Fakat yeni bir ürün geliştirilmişse bu herzaman mümkün olmayabilir. Bu tip durumlar da düşünülerek bazı umumi TSO’lar belirlenmiştir. Eğer uygun bir TSO bulunabilirse, ürün bunlardan biri altında da değerlendirilebilir. Bir hava aracı için bir cihaz tasarlayıp FAA’ye onaylatmış olmak bu cihazı üretebilme, o hava aracına monte edebilme ya da o hava aracı üzerine yerleştirilmiş cihazımız arızalandığında veya bakım yapılması gerektiğinde müdahale edebilme yeterliliğini vermez. Bu gibi durumlar için PMA ve “FAAauthorized repair station” gibi yine FAA in verdiği farklı sertifikalar vardır. Hava araçları için tasarlanmış cihazları üretebilme yetkisi Part Manufacture Approval (PMA) ile alınır. Bakım ve servis yetkisi için ise “FAAauthorized repair station” belgesi alınması gerekmektedir.[5] 5. Sonuç DO-178B şimdiye kadar sadece sivil hava araçlarında istenen bir sertifikasyon türü olduğu için ve bu tip araçların üretimi de dünyada sadece birkaç firmanın tekelinde olduğu için gündeme gelmemiş bir standarttır. Fakat son zamanlarda yazılım sektöründeki hızlı büyüme ve yazılım kullanımının kaçınılmaz artışı bu büyük firmaların alt yüklenici kullanmaya başlaması ya da bu tip hava araçlarına sonradan, yazılım içeren, ekler de yapılmaya başlanması, dahası DO-178B’nin diğer emniyet kritik sistemlerin ve askeri sistemlerin de ilgi alanına girmeye başlaması bu standarda olan ilgiyi arttırmıştır. ASELSAN’da da bu standardın bazı projelerde kullanılması gereği nedeniyle DO-178B standardı gündeme gelmiştir. Görülen odur ki ileride bu standart daha da yaygınlaşacak ve sadece sivil hava araçları ile birlikte anılmaktan çıkacaktır. Bu durumda emniyet kritik yazılım geliştiren kuruluşların bu konuda kendilerini hazırlamaları menfaatlerine olacaktır. Böyle bir projeye girilirken bu standardın getireceği fazladan maliyet ve iş gücünün farkında olunması, planlamanın ve risk analizinin buna göre yapılması gerekmektedir. Bu makalemizde DO-178B konusundaki farkındalığı arttırmaya yönelik bir çalışma ile edinilen tecrübeler, risk unsuru olan bazı faktörler, DO-178 ve ilişkili konuların genel bir tanıtımı ile beraber aktarılmaya çalışılmıştır. 6. Kaynaklar [1] RTCA, “Software Considerations in Airborne Systems and Equipment Certification”, 1 Aralık 1992. [2] HighRely Whitepaper, “DO-178B Cost Versus Benefits” [3] Esterel Technologies, “Efficient Development of Safe Avionics Software with DO-178B Objectives Using SCADE Suite”, Ağustos 2006. [4] Hilderman, Vance “Military Avionics Certification via DO-178B & DO-254”, HighRely. [5] Burkey, Ronald S. “Introduction to DO-178B”, Birds Project, http://www.sandroid.org/birdsproject/4dummies.html, son erişim: 20.08.2006.