DO-178B Sertifikasyonuna Uygun Yazılım Geliştirme Software

Transkript

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.
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
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
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
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
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
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
%
Eksiklik
%70 - %90
%50 - %75
%35 - %60
%25 - %40
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.
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.

DO-178B Sertifikasyonuna Uygun Yazılım Geliştirme Software

Transkript

Benzer belgeler

ekin arabacıoğlu

İş Analisti

Equipment Software Instructions Update

ÖZET - Düzce Üniversitesi Bilim ve Teknoloji Dergisi

Bilgisayar Yazılımında Yeni Gelişmeler Proje I İsterler

Driver yükleme işlemleri Xp bilgisayar işletim sisteminde

İş süreçlerinde zamanı sıfıra yakın sapmayla yöneten LAPIS