YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstabul) DO-178B Sertifikasyoua Uygu Yazılım Geliştirme Software Developmet Compatible with DO-178B Certificatio Yusuf İbrahim ÖZKÖK SST-MD Yazılım Mühedisliği Müdürlüğü ASELSAN A.Ş., Akara yozkok@aselsa.com.tr Serka CEYLAN SST-MD Yazılım Mühedisliği Müdürlüğü ASELSAN A.Ş., Akara ceyla@aselsa.com.tr Özet Yazılım ürülerii tekrarlaabilir ve ölçülebilir bir kalite seviyeside geliştirilmesi ve üretilebilmesi içi çeşitli stadartlar ve bu stadartları kulladığı yazılım yaşam dögüsü süreçleri taımlamıştır. Yazılım geliştire kurumlar ürülerii belli bir kalite seviyeside üretmek ve buu göstermek içi bir yazılım geliştirme stadardı kullaırlar veya bir yazılım yaşam dögüsü süreci takip ederler. Diğer tarafta üretile yazılım ürüü öemli bir sistemi parçası olacaksa veya isa hayatıı etkileyecek itelikte ise bu durumda ulusal veya uluslar arası kuruluşlar tarafıda bu tür yazılımları geliştirilme sürecii uygu stadartlarda olması isteir. Bua örek olarak Sivil hava araçları içi üretile yazılımları DO-178B stadardıa uyma zorululuğu vardır. Bu makalede DO-178B stadardı geel hatları ile taıtıldıkta sora özellikle belli bir sürece uygu yazılım geliştire bir şirketi bu stadarda geçerke takip edebileceği yollar, karşılaşabileceği zorluklar ve dikkat etmesi gereke koular deeysel bilgilere dayaılarak alatılmıştır. Abstract I order to develop ad produce software products at a quotable ad measurable quality level, various stadards ad software life cycle processes those use these various stadards are defied. Software developig corporatios use a software developmet stadard or follow a software life cycle process, i order to produce ad show their products at a certai quality level. O the other had, if the produced software product will be a part of a importat system or may affect the life of huma beig the at this circumstace for the atioal or iteratioal corporatios requests to obey a stadard for such software products. Such as the software produced for the civilia air vehicles have the obligatio to meet the objectives defied by DO-178B. I this article after DO-178B Stadard is explaied roughly, especially for the compaies which follow a certai process i software developmet, the path to follow whe switchig to this stadard, the difficulties may be met ad the issues to be take i accout are explaied based o experimetal data. 1. Giriş GATM (Global Avioics Traffic Maagemet) alaşmasıa göre tüm sivil hava araçları FAA (Federal Avioics Agecy) oayıa tabidir. Yazılımlar içi FAA oayı, DO-178B dokümaıa uyguluk alamıa gelmektedir. Buu yaıda güümüzde askeri hava ve uzay araçlarıda, ükleer satrallerde ve hatta deiz araçlarıda, ya da geelleştirirsek, emiyet kritik sistem yazılımlarıda yazılımları sistem emiyetii bozmamasıı temii içi DO-178B uyumluluğu bir sözleşme maddesi olabilmektedir. Bu makalede öcelikle DO-178B dokümaı taıtılacaktır. Bu bölüm geel bir taıtım iteliğide olacaktır. Bir makaleye sığmayacak kadar geiş ola bu kouu detaylarıa hakim olabilmek içi stadardı [1] kedisi icelemelidir. Makalei ikici bölümüde ASELSAN-SST (Savuma Sistem Tekolojileri) grubuda yazılım geliştirme süreçlerii DO-178B karşısıda değerledirilmesi çalışması soucuda ortaya çıka tespitler aktarılacaktır. Kurumsallaşmış bir yapıda stadart süreçlere uygu yazılım geliştire kuruluşları bu dokümada belirtile hedeflerde çok uzak olmadıkları söyleebilir. Yazılımları belli bir süreci çıktısı olmaya dokümatasyo kültürü yerleşmemiş firmaları, yazılımlarıı uçuşa elverişlilik sertifikasyoua sahip olabilmesi içi ise, bu doküma rehberliğide yeide yapılamaya gitmeleri gerekebilir. Referas olması açısıda bu iki aa tespit karşısıda ASELSAN ı durumu ilk sııfa girmektedir. Ortaya koacak tespitler de bu yöde olacaktır. So olarak uçuşa elverişlilik sertifikasyou e alama geldiği DO-178B i buradaki yeri ve sertifikasyo tipleride bahsedilecektir.
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstabul) 2. DO-178B Taımı ve İçeriği DO-178, RTCA (Radio Techical Commisio For Aeroautics) büyesideki özel bir heyet (SC-167) tarafıda yazılımları uçuşa elverişlilik gereklerii karşılamayı sağlaya ve edüstride geiş kabul görmüş bir rehber olması hedefi ile 1982 i ilk çeyreğide hazırlamış bir dokümadır. Bir rehber doküma olarak hazırlaa DO-178, FAA i referas alması ile bir stadart iteliği kazamıştır. Zama içide yazılım alaıdaki gelişmelere paralel olarak ve ediile geri beslemeler ile bu doküma da gücellemektedir. 1988 de RTCA bu dokümaı ikici sürümüü DO-178A adıyla, 1992 Aralık ayıda da hale kullaıla DO-178B yi [1] yayılamıştır. Bir soraki sürümü DO-178C adı ile 2009 yılı içide çıkması beklemektedir. DO-178 i idamesi RTCA ve Avrupa daki EUROCAE (Europea Orgaizatio for Civil Aviatio Equipmet) WG-12 (Work Group) örgütlemesi ile beraber yürütülmektedir. Bu çalışmaı aa amaçları şu şekilde belirlemiştir [1]; Yazılım yaşam dögüsü süreçleri içi takip edilecek hedefleri ortaya koması Bu hedeflere ulaşılabilmek içi gerekli faaliyetleri taımlaması ve tasarım yaklaşımlarıı belirlemesi Hedefleri tam olarak karşıladığıı gösterilebilmesi içi delilleri taımlaması. Bu dokümada hava araçlarıdaki sistemlerde kullaılmak üzere geliştirile yazılım ürülerii uçuşa elverişlilik sertifikasyou açısıda uyguluğu iceleir. Bir bütülük arz ede sertifikasyo sürecii alaşılabilmesi içi sistem yaşam dögüsü ile yazılım yaşam dögüsü arasıdaki ilişki de iceleme alaıa dahil edilmiştir. Bu doküma kuruluşları orgaizasyo yapısı, altyükleici gibi firmalarla ola ilişkileri ya da çalışa persoelii yetkilik durumu ve eğitim durumu gibi koularla ilgilemez. Diğer tarafta geliştirile sistemleri çalışma durumları, bu sistemlerde kullaıla tekolojiler, yazılım kodlama tekikleri, tasarım tekikleri gibi koularla da ilgilemez. Her kuruluşu kedie özgü iş yapış tarzı, kedi doküma şabloları veya kulladığı stadartlar olabilir. Uçuşa elverişlilik açısıda DO-178B dokümaıda belirtile hedefleri karşılaıyor olması yeter gerektir. Bu hedefler içide birçok detaylar olmasıa karşı işi özü açısıda eyi asıl yapılacağıı pek bir öemi yoktur. Buu yerie ortaya koa hedeflere uygu ve içeriği dokümada tespit edildiği şekilde eyi asıl yapılacağıı plalaıyor olmasıı ve tüm süreç boyuca bu plalara sadık kalıdığıı gösterilmesii asıl temeli oluşturduğu söyleebilir. Bu dokümaı içeriği ile ilgili bir bakışta bilgi edimemizi sağlayacak DO-178B dokümaı içeriğii bir haritası Şekil 1 de verilmiştir. Şekil 1: DO-178B dokümaı haritası 2.1. Emiyet Seviyeleri Uçuşa elverişlilik sertifikasyouda sistemler beş emiyet seviyesie ayrılmıştır. Bu seviyeler, sistemde oluşacak bir hataı uçağı uçuş emiyetie getireceği etkiye göre belirlemektedir. Sistemdeki bir hataı oluşturacağı etkilere göre emiyet seviyelerii taımlaması aşağıdaki tabloda verilmiştir. Bir ot olarak; bazı kayaklarda emiyet seviyesi, güvece seviyesi olarak da isimledirilebilmektedir. Tablo 1: Emiyet seviyeleri taımları Emiyet Seviyesi A B C D Hataı Oluşturacağı Etki Hataı Güveli uçuşu ve iişi egellemesi. Ölüme yol açması. Uçağı düşürmesi! Foksiyoel yeteekleri veya emiyet paylarıı ciddi şekilde azaltması. Uçuş mürettebatıı fiziksel olarak etkilemesi veya iş yapamayacak şekilde iş yüküü arttırması. Yolcuları ciddi yaralamasıa veya ölümcül yaralamalarıa sebebiyet vermesi Foksiyoel yeteekleri veya emiyet paylarıı belirgi olarak azaltması. Mürettebatı iş yüküü belirgi olarak arttırması. Yolcuları rahatsızlamasıa veya yaralamasıa sebebiyet vermesi Foksiyoel yeteekleri veya emiyet
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstabul) E paylarıı hafif olarak etkilemesi. Mürettebatı iş yüküü hafifçe arttırması. Mesela ruti işlerde bir sapma meydaa getirebilir. Yolcuları memuiyetsizliğie sebebiyet vermesi. Hiçbir etki oluşturmaması. toplam proje bütçesie yasıyacak ek maliyet ilişkisi Şekil 2 de gösterilmiştir. Bu grafik gerekli eğitim ve daışmalıklar alıdığı varsayılarak ve bir daışmalık firmasıı verilerie dayaılarak üretilmiştir. Bu şartlarda DO-178B i getireceği ek yükü %10 ile %40 arasıda olacağı belirtilmektedir. Fakat Edüstri ortalamasıı %75 ile %150 olduğu istatistiksel olarak ölçülmüştür. [2] DO-178B dokümaıda bu emiyet seviyelerie göre yazılım yaşam dögüsüde karşılaması beklee hedefler artımsal olarak belirlemiştir. Bu durum süreci, farklı emiyet seviyeleride farklı sıkılık derecelerie sahip olması soucuu doğurmaktadır. Böylece çok kritik ola bir iiş kotrol yazılımıa harcaacak çaba ile bir yolcu bilgiledirme sistemie harcaacak çaba ayı olmayacaktır. Dolayısıyla yazılımları kritiklik seviyesie göre ödeecek bedel de seviyeledirilmiş olacaktır. Burada çıkarılacak e öemli souç ise uçuşa elverişlilik sertifikasyouda sistemleri emiyet seviyelerii belirlemesii doğruda sistem maliyetie ve kullaım alaıa yasıyacağıı bilimesidir. Çeşitli sistemlerde kullaılabilecek yazılımlar açısıda ise düşük bir seviye belirlemek yazılımı kullaım alaıı daraltırke, yüksek seviye belirlemek ise oaylama işlemii gereksiz yere zorlaştıracak ve harcaacak iş gücüü ve dolayısıyla maliyeti çok fazla arttıracaktır. Özet olarak DO-178B de emiyet seviyesi yazılımı geliştirmek içi harcaacak çaba ve parayı doğruda etkileye bir parametredir. Emiyet seviyelerii isimledirilmesi ve her seviyeye karşılık yerie getirilmesi gereke hedef maddesi sayısı Tablo 2 de verilmiştir. Tablo 2: Emiyet seviyelerie göre hedef sayısı Hata Sııfı isimledirmesi Emiyet Seviyesi Hedef Sayısı Ölümcül A 66 (Catastrophic) Tehlikeli B 65 (Hazardous) Büyük (Major) C 57 Küçük (Mior) D 28 Etkisiz (No Effect) E 0 Bu tablodaki hedef maddesi sayıları sadece itelik ifade etmektedir. Nicelik olarak bir madde baze çok fazla iş gücüe karşılık geliyor olabilir. Öreği B seviyeside A seviyesie geçerke tabloda bir tae daha fazla hedefi karşılaması yetiyormuş gibi görümekle beraber, MC/DC (Modified Coditio / Decisio Coverage) yapısal kapsama aalizie karşılık gele bu maddei yerie getirilmesi içi çok ciddi bir ek işçilik harcaması gerekmektedir. Emiyet seviyelerie göre Toplam proje bütçesie gele ek yük (%) 45 40 35 30 25 20 15 10 5 0 Emiyet seviyelerie göre maliyet artışı E D C B A Emiyet Seviyeleri Şekil 2: Emiyet seviyelerie göre maliyet artışı Emiyet seviyeleri sistem seviyeside yapıla ve Sistem Emiyet Değerledirmesi (SED, ig: System Safety Assessmet, SSA) olarak isimledirile bir çalışma soucuda belirleir. Bu çalışma yazılım hatalarıı sistem hatalarıa katkısıı belirlemeye çalışır. SED ile FTA (Fault Tree Aalysis), FMCEA (Failure Modes, Effects ad Criticality Aalysis) gibi yötemlerle oluşabilecek hataları souçları aaliz edilir ve buu soucuda yazılım içi emiyet gerekleri türetilir. Bu çalışmaı öemii vurgulamak içi şöyle bir örek verebiliriz; yazılımları doğrulaması ve hatasız olması yazılım gerekleri alamıda değer taşır. Fakat oluşacak özel bir durumda yazılım gereklerii sebep olacağı bazı kısıtlar sistemi emiyetsiz bir duruma girmesie yol açabilir. Böyle bir durumda yazılım sıfır hatayla çalışsa bile sistem emiyeti ortada kalkabilir. DO-178B de her e kadar eyi asıl yapılacağıa karışılmasa da sistem emiyetii sağlamaya yöelik bazı öeriler de verilmiştir. Bular hafıza bölümleme, çoklu versiyo-farklı yazılımlar, sistemde emiyet izleme özelliğii buluması tarzıda öerilerdir [1]. 2.1. Yazılım Yaşam Dögüsü Süreçleri DO-178B belli bir yazılım yaşam dögüsü modeli öe sürmek yerie çoğu modelde bulua süreçleri ayrık olarak detaylı bir şekilde alatmıştır. Bu süreçler uygu bir şekilde orgaize edilerek şelale modeli, sarmal model v.s. gibi yazılım yaşam dögüsü bezeklerie uygulaabilir. 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, İstabul) dışıdaki bezekler içi uygulamaı gereksiz bir zorlama olacağı söyleebilir. Daha açık bir ifade ile bu rehber dokümada alatıla süreçlere e uygu bezek artımsal şelale modelidir. DO-178B de şu süreçler alatılmıştır (bkz. Şekil 3); Yazılım plalama süreci Yazılım geliştirme süreci Yazılım doğrulama süreci Yazılım kofigürasyo yöetim süreci Yazılım kalite güvecesi süreci Sertifikasyo makamı irtibat süreci Bu liste so madde hariç yazılım mühedisleri içi çok bilie yaşam dögüsü süreçleri listesidir. So madde ise uçuşa elverişlilik sertifikasyou söz kousu olduğuda doğal olarak ortaya çıka bir süreçtir. DO- 178B de her süreç, o süreci amaçları, o süreçte yapılması gereke çalışmalar, süreci çıktıları ve süreci tamamlama ölçütleri aa başlıkları altıda ayrıtılı bir şekilde alatılmıştır. Hem sertifikasyo makamı ve hem de bu stadardı ruhu açısıda plalama ve doğrulama süreçlerii diğerleride ayrıla özel bir yeri vardır. Plalama Doğrulama Yötemleri Tamamlayıcı Süreçler Sertifikasyo Sistem Gereksiimleri Stadartlar Stadartlar, ortam taımı Kofigürasyo Yöetim Gereksiimler, Tasarım ve Kod Şekil 3: DO-178B Süreç Haritası [3] Geliştirme Doğrulama Souçları Doğrulama Test Kalite Güvecesi Sertifikasyo otoriteleri açısıda e öemli kou plalamadır. İlk olarak plalar iceleir ve sorasıda bu plalara uyguluk kotrol edilir. Doğrulama sürecide çoğu zama sadece yazılımı gereklere uyguluğuu doğrulaması ve yazılım test süreçleri alaşılır. Fakat burada doğrulama süreci yazılım testii yaı sıra tüm yapılaları plalara ve DO- 178B hedeflerie uyguluğuu doğrulaması alamıa da gelmektedir. Ayrıca doğrulama süreci içeriside testlere ilavete yapılması gereke test kapsama aalizi de DO-178B i ayırt edici bir özelliği olarak belirtilebilir. DO-178B de Şekil 3 teki süreç haritasıı ürüleri olarak Tablo 3 teki çıktılar taımlamıştır. Bu listede olarak sııfladırıla çıktılar her seviye içi üretilmesi gereke çıktılardır. Diğer çıktılar üretilip üretilmeyeceği ise emiyet seviyesie bağılıdır. Ayrıca emiyet seviyesie bağlı olarak bu çıktıları içerikleri de değişebilmektedir. DO-178B dokümaıda tüm çıktılar ve içerikleri detaylı olarak alatılmıştır. Tablo 3 DO-178B çıktıları listesi Kısaltma Adı Tip PSAC Pla for Software Aspects of Certificatio SDP Software Developmet Pla SVP Software Verificatio Pla SCMP Software Cofiguratio Maagemet Pla SQAP Software Quality Assurace Pla SRS Software Requiremets Stadart Stadards SDS Software Desig Stadards Stadart SCS Software Code Stadards Stadart SRD Software Requiremets Data SDD Software Desig Descriptio - Source Code Kod - Executable Object Code Biary SVCP Software Verificatio Cases ad Procedures SVR Software Verificatio Results Kayıt SECI Software Life Cycle Eviromet Cofiguratio Idex SCI Software Cofiguratio Idex - Problem Reports Kayıtlar - Software Cofiguratio Maagemet Records Kayıt - Software Quality Assurace Records Kayıt SAS Software Accomplishmet Summary 3. Kedi süreçlerie sahip kurumsallaşmış bir şirkette DO-178B i uygulaması İlk defa DO-178B stadardıa uygu yazılım geliştirecek, AQAP-160, CMM gibi stadartları uygulaya şirketler bazı zorluklarla ve uyum soruları ile karşılaşabilirler. Buu da öteside DO-178B i
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstabul) uygulamasıı getireceği ek iş gücü olması gerekei çok daha üstüde gerçekleşebilir. E kötüsü ise proje souda sertifikasyo sürecide soruları çıkması olacaktır ki bu tüm süreci tekrarlamasıı gerektirebilir. Bu tip riskleri miimize etmek içi kouu başta görümeye ve acak tecrübe ile kazaılabilecek yalarıı bilimesi gerekir. Bu bölümde bizim edidiğimiz deeyimler ve karşılaştığımız sorularla ilgili bazı bilgiler aktarılmaya çalışılacaktır. Uçuşa elverişlilik sertifikasyoua yöelik yazılım geliştirmek; sadece bu işi stadardı ola DO-178B dokümaıı okuyup alamak ve uygulamak şeklide alaşılmamalıdır. Bu dokümada tariflee hedefleri karşılaabilmesi içi belli bir iş yapış matığıı yerleştirilmesi ve bilgi birikimi gerekmektedir. Bu bilgi birikimide, kurumu kulladığı doküma şablolarıda, kullaıla otomatik test araçlarıa yazılım geliştirme yötemlerie kadar aslıda çok uzu sürede kazaılabilecek bir kurumsal bilgi dağarcığı (kow-how) alaşılmalıdır. Şu uutulmamalıdır ki; süreç eşittir doküma demek değildir! Alt bölümlerde yazılım şirketlerii mevcut bilgi dağarcığıa e kısa sürede DO-178B uyumluluğu kazadırmak içi uygulaabilecek seçeekler dikkat edilmesi gereke koular ve e souda da gerçek bir durum çalışması verilmiştir. 3.1. Kurumsal bilgi dağarcığıı uyumladırılması Kurumsal bilgi dağarcığıı e hızlı şekilde bu stadarda uyumladırmak içi tespit ettiğimiz bazı yollar şulardır; Eğitim almak, Daışmalık hizmeti almak, DER (Desigated Egieerig Represetative) kiralamak, Sertifikasyo gereği ola bir projei parçası olmak. Eğitim: Düya çapıda bu kouda uzmalaşmış üç dört büyük kuruluşta biride 1 haftalık DO-178B eğitimi alıabilir. Bu sayede sertifikasyoa tabi bir projedeki isa kayağıa hızlıca DO-178B adaptasyou sağlaabilir. Bu eğitimler dâhilide çoğu zama süreç çıktılarıı oluşturulması içi kullaılabilecek doküma şabloları kotrol listeleri gibi çok değerli kayaklar da verilmektedir. Bu seçeeği bir dezavatajı bir haftalık yoğu bir eğitimde uygulama alışkalıklarıı değiştirilemeyeceğidir. Bu yüzde bizim öerimiz bu seçeeği tek başıa yeterli olacağı düşüülmemeli ve beraberide soraki üç seçeekte biri de uygulamalıdır. Daışmalık hizmeti almak: Eğitim vere bu belli başlı kuruluşlar ayı zamada daışmalık hizmeti de sumaktadırlar. Daışmalık belli aralıklarla ayrık zamalarda ortaya çıka soruları giderilmesi amacıyla olabileceği gibi tüm proje süresice projei gidişatıı sürece uyguluğuu takibi şeklide de olabilir. DER kiralamak: DER, sertifikasyo makamıı yetkiledirdiği ve oay yetkisi ola süreci tetkik edip geri besleme vererek gidişatı kotrol edebilecek bağımsız bir uzma kişidir. Uçuşa elverişlilik sertifikasyou istee projelerde, projeye atamış bir DER buluması zate bir zorululuktur. Sertifikasyou şart olmadığı fakat sertifikaladırılabilir itelikte olması istee bir DO- 178B projeside de projei başlarıda bir DER kiralayarak projei her aşamasıda oay alıarak da devam edilebilir. Böylece proje souda projemiz otomatik olarak oaylamış olacaktır. Fakat sertifikasyou şart olmadığı sadece bir kalite stadardı amaçlaa ve özellikle gizlilik arz ede askeri projelerde bu yötem pek tercih edilmez. Sertifikasyo gereği ola bir projede alt yükleici olmak: Böyle bir imkâ var ise ilk defa DO-178B uyumlu yazılım geliştirecek bir firma içi e uygu ve verimli seçeek bu olabilir. Bu durumda süreci takibii büyük ölçüde üst yükleici yapacak ve sizi gerektiği şekilde yöledirecektir. Büyük ihtimalle üst yükleici bir DER kiralamış veya daışmalık hizmeti alıyor olacaktır. Bu imkâlarda alt yükleici firma da yararlaabilecektir. Tüm süreç çıktıları üst yükleici firma tarafıda tekrar gözde geçirilecek ve bir bakıma sorumluluk da dağıtılmış olacaktır. 3.2. sıkılığıı emiyet seviyesie göre değişmesi DO-178B de yazılımları emiyet seviyelerie göre sııfladırıldığı, süreci sıkılığıı bu seviyelere göre değiştiği ve seviye azaldıkça karşılaması beklee hedefleri azaldığı akılda çıkarılmamalıdır. Belli bir süreci uygulaya yazılım şirketleri tüm yazılım ürülerii ayı süreçte geçirirler. DO-178B de seviyeleri farkıda olumazsa bu matığa takılıp gereksiz çalışmalar yapılabilir. Bu duruma düşmekte kaçıılmalıdır! 3.3. tasyo uyumlaması DO-178B de taımlı süreç çıktıları büyük ölçüde düyada kabul görmüş yazılım geliştirme süreçleri çıktıları ile ayıdır. Buu yaıda DO-178B ye özel
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstabul) bazı ek çıktılar olabilmektedir. Şirketimizi sürecide olmaya ama DO-178B de istee çıktılar olabilir. Bu çıktıları taımlaıp gerekli umaraladırmalarıı yapılması kofigürasyo yöetimi sistemi içie alıması gerekmektedir. Diğer bir kou da doküma şablolarıdır. DO-178B dokümalar içi belli bir şablo ögörmemektedir. Sadece her dokümaı içide olması gereke koular listelemiştir. Fakat sertifikasyo sürecide sertifikasyo otoritelerii öüe gele dokümaları belli bir düzede olması daha açık bir ifade ile sertifikasyou yapa kişileri alışık oldukları yapıda olması sertifikasyo sürecii hızladırması ve kolaylaştırması alamıda öemlidir. Bu edele doküma şablolarıı daışmalık şirketleride veya başka kayaklarda temi edilecek DO-178B uyumlu şablolarla karşılaştırılması, gerekiyorsa gücellemesi yeride bir davraış olur. 3.4. Yazılım geliştirme ortamı ve araçlarıda araıla uyumluluk Her yazılım şirketii, dahası her yazılımcıı geliştirdiği yazılım tipie bağlı olarak kulladığı bir yazılım geliştirme ortamı ve araçları, kulladığı çeşitli yazılım kütüphaeleri vardır. Stadart yazılım geliştirme süreçleride yazılımları üretilmeside büyük katkısı/etkisi ola bu üçücül kayaklar pek sorgulamaz. Fakat DO-178B stadardıda yazılım ürüüü etkileye her şey sertifikasyoa tabidir, dolayısıyla buları da oaylaması gerekir. Yazılım araçları iki sıı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ı bir parçası ola araçlar bu sııfa girer. Öreği tasarımda otomatik kod ürete araçlar ya da derleyiciler. Eğer bu tip araçları ürettiği çıktı DO- 178B doğrulama yötemlerie göre doğrulamayacaksa bu aracı oaylı (qualified) bir araç olması gerekir. Yazılım doğrulama araçları: Bu sııftaki araçlar; çıktısı yazılımı bir parçası olmaya fakat süreci etkilediği içi hataları tespitii egelleyebilecek araçlar olarak tarif edilmiştir. Öreği test araçları, aaliz araçları, statik kod aalizi araçları. Eğer bu araçları ürettiği çıktılar DO-178B ye göre doğrulamada kullaılmak isteiyorsa bu araçları oaylı olması gerekmektedir. DO-178B ye göre yazılım yaşam dögüsü süreci içide kullaıla bir aracı oaylamasıı gerekip gerekmediği aşağıdaki üç soruya verile cevaplara göre belirleebilir. 1. Bu araç yazılım ürüü içide hatalar oluşturabilir veya mevcut bir hataı tespit edilmesii öleyebilir mi? 2. Bu aracı çıktısı DO-178B bölüm 6 altıdaki doğrulama adımlarıda doğrulamayacak mı? 3. Bu araç DO-178B süreçleride bir otomasyo ya da basitleştirme sağlıyor mu? Eğer bu üç soruya evet cevabı veriliyorsa bu aracı oaylı olması gerekmektedir. Yazılım araçları dışıda yazılımımızda kullaacağımız kütüphaeleri ya da RAHAT (Rafta Hazır Ticari) ürüleri de sertifikalı olması ya da bizim tarafımızda DO-178B stadartlarıa uygu hale getirilmesi gerekmektedir. Bu durum kullaabileceğimiz hazır kütüphaeler içi düyada oluşmuş ola çok geiş bir yazılım arşivide yararlamamamıza ve sadece çok kısıtlı ola sertifiye edilmiş ürülerle sıırlı kalmamıza ede olmaktadır. Bu kısıtlarda dolayı yazılım firmaları uzu süreler boyuca oluşturdukları kedi yazılım kütüphaelerii ve oluşturdukları yazılım geliştirme ortamlarıı bir tarafa koyup yei kayaklar aramak ve yei bir geliştirme ortamı oluşturmak zoruda kalabilirler ki bu durum hem maliyet hem de zama açısıda çok büyük bir egeldir. 3.5. Fark Aalizi (Gap Aalysis) Profesyoel olarak yazılım geliştire her firmaı belli bir yazılım geliştirme süreci bulumaktadır. Bu süreci DO-178B ye uygulaştırılması içi düzeltilmesi ve/veya eklemesi gereke süreçleri ve süreç çıktılarıı belirlemesie yöelik yapıla çalışmaya fark aalizi (Gap Aalysis) deir. Düyada çeşitli daışmalık şirketleri bu hizmeti vermektedir. Böyle bir fark aalizi çalışması aalizi yapılacağı kurumu süreçlerii iyi bile bir uzmaı da çalışmaya dahil olması şartı ile 2-4 adam/hafta gibi bir sürede tamamlaabilmektedir. Bir daışmalık firması öceki tecrübelerii aaliz ederek CMM seviyelerie göre DO- 178B B seviyesi örtüşme oralarıı çıkartmıştır. Bu çalışmaı souçları Tablo 4 ve Tablo 5 de verilmiştir. [4] Tablo 4: CMM Seviyelerii DO-178B B seviyesii Kapsama Oraı SEI CMM Seviyesi % Eksiklik SEI CMM Level 1 Orgaizatio %70 - %90 SEI CMM Level 2 Orgaizatio %50 - %75 SEI CMM Level 3 Orgaizatio %35 - %60 SEI CMM Level 4 Orgaizatio %25 - %40
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstabul) SEI CMM Level 5 Orgaizatio %20 - %35 Tablo 5: DO-178B Süreçlerii Örtüşme Oraları (CMM-3 te DO-178B B seviyesie) Sertifika Faaliyeti Eksiklik Oraı PSAC %80 QA Pla %20-30 CM Pla %10-20 Developmet Pla %40-50 Software Verificatio Pla %60-70 Safety Assesmet %80-90 Requiremets Defiitio %20-30 Desig %10-15 Code %5-10 Fuctioal Test %5-10 Structural Coverage Test %90-100 CM %10-30 QA %50 Tool Qualificatio %100 Checklists %30-50 Reviews %30-50 Audits %30-50 DER Liaiso %100 Not: %0 eksiklik %100 örtüşme alamıa gelir. ASELSAN da bezer bir çalışma daışmalık alımada yapılmıştır. Bu çalışma soucuda uyguladığımız süreci DO-178B ye karşılık geldiği seviye ortaya çıkartılmıştır. Fakat tam olarak bu seviyei karşılaabilmesi içi bazı doğal olarak yapıla fakat resmi olarak sürecimizde bulumaya belgeledirilmemiş çalışmaları da disiplie edilerek resmileştirilmesi ve tabi ki sertifikasyoa özel ek doküma ve çalışmaları da sürecimize eklemesi gerektiği ortaya çıkmıştır. Buu yaıda, bu seviyede istemeye fakat sürecimizde bulua birçok ek faaliyeti de çıkartılması, gereksiz maliyet artışıı öüe geçilmesi adıa gereklidir. 3.6. Durum çalışması Hâlihazırda ASELSAN da DO178-B seviye D/C ye göre geliştirmekte olduğumuz bir projei stadart yötem ile geliştirilmesi durumuda oluşa maliyet karşılaştırması gerçek veriler birim ile ifade edilerek Tablo 6 de verilmiştir. Tablo 6: Gerçek bir maliyet karşılaştırması DO178-B D/C Seviyesie Göre Yazılım Geliştirme Stadart Yazılım Geliştirme (birim) (birim) Altyapı Giderleri 1960 710 Sertifikasyo Giderleri 4225 - İşçilik Giderleri 169 121 Toplam Gider 6354 831 DO178-B seviye D/C ye göre yazılım geliştirmedeki giderleri stadart yazılım geliştirmede harcaa 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şte kayaklaa yatırım maliyetleri olduğu gözde kaçırılmamalıdır. DO178-B uyumlu yazılım geliştirme içi kullaıla işletim sistemi, geliştirme ortamı ve test araçlarıı özel olması edeiyle maliyetlerii stadart ürülere kıyasla çok daha pahalı olduğu görülmektedir. DO178- B seviye D/C ye göre yazılım geliştirmede e büyük gideri sertifikasyo kalemii oluşturduğu görülmektedir. Bu kalem kullaıla geliştirme ortamları, test yazılımları ve hazır kütüphaeleri sertifikasyo materyallerii maliyetide oluşmaktadır. İşçilik giderlerii farklılığıdaki e büyük etke ise geliştirile yazılımı sertifikasyo gereklerii yerie getirmek içi harcaa ek çabadır. 4. Sertifikasyo Bu bolümde uçuşa elverişlilik sertifikasyouu eyi ifade ettiği ve yazılımı bu kavram içideki yeri alatılacaktır. DO-78B ile ilgili belgelerde bu kavram çoğu zama karıştırılmakta veya hiç alatılmamaktadır. Tek başıa DO-178B sertifikasyou diye bir şey yoktur. Sivil hava araçlarıda uçuşa elverişlilik sertifikasyou dâhilide yazılım ürülerii sertifikasyou sadece bir bölümü oluşturur. Souçta sertifikasyo deilice söz kousu ola doaım ve yazılımda oluşa bir sistemi bütüüdür. Bir hava aracı veya sistem sertifikasyou bir FAA projesi açılmasıı takibe, FAA proje umarası alıması ile başlar. Öerilmemekle beraber FAA projesi açtırmada da projei herhagi bir aşamasıda veya souda sertifikasyo içi başvurulabilir. Bu durumda FAA i öemli öerileride ve etkileşimde mahrum olarak geliştirile proje i uygu görülmeme ihtimali yüksektir. Emiyet seviyesi ile oratılı olarak süreçler arası ilişkii artması edeiyle özellikle C seviyeside sora istee ek gerekleri karşılamak birçok işi tekrarlamasıı gerektireceği içi projei toplam iş yüküe yakı bir iş yükü getirebilir. Bir FAA projesi şu üç sertifikasyo tipi içi açılabilir.
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstabul) 1. TC (Type Certificate) 2. STC (Supplemetal Type Certificate) 3. TSO (Techical Stadard Order) TC bir hava aracıı tamamıı sertifikasyou alamıa gelmektedir. Bu hava aracıı üzerideki bütü fabrikasyo birimler de bu TC ye dâhildir. Hava aracıa sorada ekleecek cihazlar içi ise STC olarak adladırıla sertifikasyo uygulaır. STC, TC ye bir ek gibi düşüülmelidir. Her STC sadece bir TC ye ait olabilir. Yai bir hava aracı içi geliştirile bir cihaz başka bir hava aracıa ayı STC ile takılamaz. Buu içi diğer hava aracıı TC si altıda bir STC alıması gerekmektedir. Geel geçer birimler içi TSO adı altıda üçücü bir sertifikasyo türü vardır. Her hava aracıa ya da birde fazla hava aracıa takılmak üzere geliştirile cihazlar TSO ya tabi olabilir. TC sadece hava aracı üreticilerii başvurabileceği bir sertifikasyodur. STC ye ise hava araçları içi yei birimler ürete ispete küçük firmalar da başvurabilir. Fakat STC hagi TC içi alıacaksa o hava aracıa sahip bir firma ile öcede alaşmış olmak gerekmektedir. Çükü STC i ilgilediği hava aracıı cihazı ürete üretici tarafıda ulaşılabilir olması şartı vardır. Tabii ki bu hava aracı satı alıarak ya da kiralaarak da bu şart sağlaabilir! TSO içi ise öcede belirlemiş sııfladırmalar vardır. Üretile cihaz daha öcede üretile cihazlara göre belirlemiş TSO sııfladırmalarıda birie giriyorsa, cihaz bu TSO ile sertifikaladırılabilir. Fakat yei bir ürü geliştirilmişse bu herzama mümkü olmayabilir. Bu tip durumlar da düşüülerek bazı umumi TSO lar belirlemiştir. Eğer uygu bir TSO buluabilirse, ürü bularda biri altıda da değerledirilebilir. araçları üretimi de düyada sadece birkaç firmaı tekelide olduğu içi güdeme gelmemiş bir stadarttır. Fakat so zamalarda yazılım sektörüdeki hızlı büyüme ve yazılım kullaımıı kaçıılmaz artışı bu büyük firmaları alt yükleici kullamaya başlaması ya da bu tip hava araçlarıa sorada, yazılım içere, ekler de yapılmaya başlaması, dahası DO-178B i diğer emiyet kritik sistemleri ve askeri sistemleri de ilgi alaıa girmeye başlaması bu stadarda ola ilgiyi arttırmıştır. ASELSAN da da bu stadardı bazı projelerde kullaılması gereği edeiyle DO-178B stadardı güdeme gelmiştir. Görüle odur ki ileride bu stadart daha da yaygılaşacak ve sadece sivil hava araçları ile birlikte aılmakta çıkacaktır. Bu durumda emiyet kritik yazılım geliştire kuruluşları bu kouda kedilerii hazırlamaları mefaatlerie olacaktır. Böyle bir projeye girilirke bu stadardı getireceği fazlada maliyet ve iş gücüü farkıda oluması, plalamaı ve risk aalizii bua göre yapılması gerekmektedir. Bu makalemizde DO-178B kousudaki farkıdalığı arttırmaya yöelik bir çalışma ile ediile tecrübeler, risk usuru ola bazı faktörler, DO-178 ve ilişkili kouları geel bir taıtımı ile beraber aktarılmaya çalışılmıştır. 6. Kayaklar [1] RTCA, Software Cosideratios i Airbore Systems ad Equipmet Certificatio, 1 Aralık 1992. [2] HighRely Whitepaper, DO-178B Cost Versus Beefits [3] Esterel Techologies, Efficiet Developmet of Safe Avioics Software with DO-178B Objectives Usig SCADE Suite, Ağustos 2006. [4] Hilderma, Vace Military Avioics Certificatio via DO-178B & DO-254, HighRely. [5] Burkey, Roald S. Itroductio to DO-178B, Birds Project, http://www.sadroid.org/birdsproject/4dummies.html, so erişim: 20.08.2006. Bir hava aracı içi bir cihaz tasarlayıp FAA ye oaylatmış olmak bu cihazı üretebilme, o hava aracıa mote edebilme ya da o hava aracı üzerie yerleştirilmiş cihazımız arızaladığıda veya bakım yapılması gerektiğide müdahale edebilme yeterliliğii vermez. Bu gibi durumlar içi PMA ve FAAauthorized repair statio gibi yie FAA i verdiği farklı sertifikalar vardır. Hava araçları içi tasarlamış cihazları üretebilme yetkisi Part Maufacture Approval (PMA) ile alıır. Bakım ve servis yetkisi içi ise FAAauthorized repair statio belgesi alıması gerekmektedir.[5] 5. Souç DO-178B şimdiye kadar sadece sivil hava araçlarıda istee bir sertifikasyo türü olduğu içi ve bu tip