Emniyet-Kritik Sistemlerin Yazılım Doğrulama Süreci

YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
Emniyet-Kritik Sistemlerin Yazılım Doğrulama Süreci
Software Verification Process in Safety-Critical Systems
Mehmet Özbek
Bilişim Teknolojileri Enstitüsü,
TÜBİTAK MAM, Kocaeli
Ayşegül Kurt
Bilişim Teknolojileri Enstitüsü,
TÜBİTAK MAM, Kocaeli
Ali Gürbüz
Bilişim Teknolojileri Enstitüsü,
TÜBİTAK MAM, Kocaeli
[email protected]
[email protected]
[email protected]
Özet
Günlük hayatın her alanında karşılaşılan yazılım, her
geçen gün daha da yaygın bir şekilde kullanılmaktadır.
Emniyet-kritik sistemler yazılımın önemli kullanım
alanlarından biridir. Günümüzde kimyasal madde
üretimi yapan fabrikalardan, nükleer santrallere,
nükleer tıpta kullanılan biyomedikal cihazlardan, uçak,
helikopter ve hızlı tren gibi ulaşım araçlarına, oradan
silah sistemleri ve uzay araçlarına kadar birçok
emniyet-kritik sistemin kontrolü emniyet-kritik
yazılımlarla gerçekleştirilmektedir. Bu sistemlerin
kullanımları sırasında meydana gelebilecek en küçük
bir hata bile önemli can ve mal kayıplarına neden
olabilir. Oluşabilecek muhtemel kazalar can ve mal
kaybının yanında, çevre için de önemli zararlara neden
olabilirler. Bu nedenle bu tür sistemlerin kontrolünde
kullanılan emniyet-kritik yazılımların doğrulama
sürecinin başarılı bir şekilde gerçekleştirilmesi ayrı bir
önem arz etmektedir. Bu çalışma kapsamında emniyetkritik sistemlerdeki yazılımların doğrulama süreci
anlatılmıştır. Donanım doğrulama süreci bu çalışma
kapsamında ele alınmamıştır.
Abstract
In daily life software is everywhere in most fields and
becoming much more popular day by day. Nowadays
safety-critical software is used to control many types of
systems from factories producing chemicals to nuclear
power plants, from biomedical equipments used in
nuclear medicine to transport systems like aircrafts,
planes, helicopters, weapon systems and rapid trains.
During the use of these systems any simple defect may
cause serious accidents leading life or equipment
(system) loss and ecological disasters. Thus the success
of verification process of safety-critical software used in
such kinds of systems is much more important. In this
study the verification process of safety-critical software
is explained. Hardware verification process is out of the
scope of this study.
1. Giriş
Emniyet-kritik sistem, herhangi bir hataya bağlı kaza
olması durumunda:
• Can kaybı veya ciddi yaralanma,
• Ekipmanın kaybı veya ciddi bir şekilde hasar
görmesi,
• Çevrenin büyük zarar görmesi
gibi sonuçlara neden olabilecek sistemlere denir.
Emniyet-kritik yazılımlar ise bu sistemlerde kullanılan
yazılımlara denir.
Emniyet-kritik yazılımların kullanımı her geçen gün
yaygınlaşmaktadır. Bu tür yazılımlar nükleer
reaktörlerin
kontrolünde,
zararlı kimyasalların
üretildiği ve kullanıldığı endüstriyel merkezlerin
kontrol sistemlerinde, radyasyon kullanan tıp
cihazlarında önemli bir kullanım alanı bulmaktadır.
Emniyet-kritik yazılımlar ayrıca kara/hava/deniz
platformlarında kullanılan silah sistemlerinde, uzay
araçlarında, uçak, helikopter, hızlı tren gibi ulaşım
araçlarında da kullanılmaktadır. Bu yazılımlar
günümüzde otomotiv sektöründe de kullanılmaya
başlanmıştır.
Tüm bu sistemlerde meydana gelebilecek en küçük bir
hata olumsuz sonuçlar doğurabilir. Emniyet-kritik
sistemlerde oluşabilecek hatalar yazılım kaynaklı,
donanım kaynaklı veya insan faktörüne bağlı olabilir.
Bu sistemlerin donanımları genellikle yedekli olarak
tasarlanır ve arıza durumunda kesintiye uğramadan
çalışmaya devam edebilmeleri sağlanır. Bu sistemlerin
yazılımlarının da özel bir şekilde geliştirilmesi,
kullanıma sunulmadan önce olası tüm hatalardan
arındırılması gereklidir [1]. Bu nedenle bu tür
sistemlerin otomasyonunda kullanılan emniyet-kritik
yazılımların geliştirilmesi ve doğrulanması ayrı bir
önem taşımaktadır.
Yazılımda bulunan bir hatayı tespit etmek genelde
donanım hatasını tespit etmekten daha zordur. Bu
durum hatanın giderilmesi için de söz konusudur.
Emniyet-kritik yazılımların içerdikleri olası hatalar,
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
yazılımın üzerinde çalıştığı donanımı da (dolayısı ile
tüm sistemi) devre dışı bırakıp tehlikeli sonuçlara yol
açabileceğinden bu tür yazılımlar kullanılmadan önce
sistematik bir doğrulama sürecinden geçirilmelidir.
Böylelikle yazılımdan kaynaklanacak tehlikelerinin
önceden belirlenmesi ve bunlar için önlem alınması
sağlanır. Bu çalışma kapsamında emniyet-kritik
yazılımlar geliştirilirken kullanılan doğrulama süreci
anlatılacaktır.
2. Yazılım Doğrulama Süreci
Doğrulama süreci, geliştirilen sistemin, tam olarak
istenen sistem olduğunu, kendisinden beklenen
davranışları gerçekleştirdiğini ve sistemde istenmeyen
özelliklerin bulunmadığını, istenmeyen davranışlar
göstermediğini ortaya koyan süreçtir. Yazılım
geliştirmede,
geliştirilen
sistemin
müşteri
gereksinimlerini tam olarak karşıladığı ve yazılım
geliştirmenin her evresindeki çıktıların doğru olduğuna
karar verilmesi gerekir. Bu kararı verme süreci, yazılım
doğrulama sürecidir. Doğrulama süreci, bu gibi
nedenlerle yazılım geliştirmede en önemli süreçlerden
birisidir. Böylelikle yazılımın kusursuz olarak çalışması
sağlanır.
Yazılım doğrulama sürecinin temel amacı, geliştirilen
yazılımda bulunan olası hataları ortaya çıkarmak ve
bunların sonunda gerekli düzeltici eylemleri
gerçekleştirmektir. Bu sürecin planlanması ve
uygulanması, yazılım geliştirme sürecinin mümkün
olduğunca erken evrelerinde başlatılmalıdır [2].
Yazılım
projelerinde
gerçekleştirilen
yazılım
doğrulama süreci iki aşamada gerçekleştirilir. Bunlar
gözden geçirmeler ve yazılım testleridir.
Yazılım
Doğrulama
Statik
Doğrulama
Gereksinim
Belirtimleri
Ön
Tasarım
Detay
Tasarım
Yazılım
Gerçekleme
Şekil 1: Yazılım doğrulama yöntemleri
Dinamik
Doğrulama
Gözden geçirmeler statik doğrulama, yazılım testleri ise
dinamik doğrulama yöntemidir [3,4]. Gözden
geçirmeler (statik doğrulama), bir yazılım ürününün
hedeflenen kullanıma uygunluğunu incelemek, kendi
belirtimlerinden ve standartlardan sapmalarını tespit
etmek
amacıyla
gerçekleştirilen
sistematik
değerlendirmelerdir [5].
Yazılım Testleri (dinamik doğrulama), kaynak kodun
çalıştırılarak bir yazılım ürününün kendisinden
beklenen işlevsel davranışları gösterdiğini, kusurlar
içermediğini ortaya koymak için hazırlanan test
durumlarının koşturulmasıyla gerçekleştirilen eylemler
dizisidir.
Şekil-1, yazılım doğrulama sürecini şematik olarak
göstermektedir. Statik doğrulama, yazılım yaşam
döngüsünde her evre ile ilgilenirken, dinamik
doğrulama sadece geliştirilen yazılım ile ilgilenir.
Statik doğrulama; yönetimsel gözden geçirme, teknik
gözden geçirme, üzerinden geçme (walkthrough),
inceleme (inspection), denetleme (audit) gibi çeşitli
gözden geçirme teknikleri ile gerçekleştirilirken,
dinamik doğrulama ise işlevsel, yineleme (regression),
performans, yükleme, stres, güvenlik, vb. testlerle
gerçekleştirilir.
Gözden geçirmelerin amaçlarından bazıları:
• Yazılım yaşam döngüsünün her evresinde
üretilen bütün dokümanların amaçlarına
uygun olarak üretildiğini,
• Gereksinimlerin tam, tutarlı, test edilebilir vb.
özellikleri karşıladığını,
• Tasarımın belirlenen gereksinimlere uygun,
tutarlı ve gerçekleştirilebilir olduğunu,
• Üretilen kaynak kodun tasarımı tam olarak
gerçeklediğini,
ortaya koymaktır [6].
Gereksinimlerin gözden geçirilmemesi durumunda
gereksinimdeki eksiklikler veya çelişkilerin ya farkına
varılamayacak ya da yazılım yaşam döngüsünün ancak
ilerlemiş evrelerinde tespit edilecektir. İleriki evrelerde
tespit edilen hataların düzeltilmesi daha uzun düzeltici
faaliyetlere neden olacağından, proje takviminin
uzaması ve maliyetin artması riski ile karşılaşılacaktır.
Gereksinim gözden geçirmenin amaçlarından biri de
gereksinimin tasarım, gerçekleme ve testleri yapmak
için yeterli detayı içerip içermediğinin tespit
edilmesidir.
Kod
gözden
geçirmeler
üzerinden
geçme
(walkthrough) şeklinde gerçekleştirilir. Bu teknikte
amaç, kod içerisindeki mantıksal hataları, geliştirilen
kodun kodlama standartlarına uymadığı durumları ve
koddaki hatalı durumları
(ilklendirilmemiş
değişkenler, tanımlanmış ve hiç kullanılmamış
değişkenler vb.) tespit etmektir.
Statik doğrulama hata önleme ve tespitinde önemli bir
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
role sahip olup yazılım geliştirmenin erken evrelerinde
bu gibi tespitlerin yapılmasını sağladığı için, proje
maliyetinin artmasına ve proje takviminin uzamasına
engel olarak projenin başarı ile tamamlanmasını sağlar
[6].
Dinamik
doğrulama
yazılımın
geliştirilmesi
tamamlandıktan sonra, test eylemleriyle gerçekleştirilir.
Yazılım projelerinde gerçekleştirilen yazılım testlerinin
amacı hataların varlığının ortaya konulmasıdır. Testler
ile yazılımda hataların varlığı ortaya çıkarılır, yokluğu
gösterilmez [7]. Başarılı bir test bir veya birden fazla
hatanın bulunmasını sağlayan testtir.
Statik ve dinamik doğrulama birbirini bütünleyen iki
tekniktir. Birbirine karşı olan iki doğrulama tekniği
değildir. Yazılım doğrulama sürecinde her ikisi birlikte
kullanılmalıdır.
Gözden
geçirmeler
yazılımın
belirtimlere ve standartlara uygunluğunun kontrol
edilmesi olduğundan bu doğrulama yöntemi ile işlevsel
ve performans, güvenlik gibi işlevsel olmayan özellikler
kontrol edilemez. Statik doğrulama tek başına,
geliştirilen
yazılımın
müşterinin
gerçek
gereksinimlerine uygun olduğunu garanti edemez. Bu
amaçla gözden geçirmelere yani statik doğrulamaya
bütünleyici olarak yazılım testleri yani dinamik
doğrulama gerçekleştirilir.
3. Emniyet-Kritik Yazılım Doğrulama Süreci
Emniyet-kritik yazılımlarının doğrulama sürecinin
temel amacı, yazılımın kusursuz olarak çalışmasının
yanında güvenilir (safe) olarak geliştirilmesini
sağlamaktır. Emniyet-kritik yazılımlar için doğrulama
süreci,
emniyet-kritik
olmayan
yazılımlardaki
doğrulama sürecinde olduğu gibi statik ve dinamik
doğrulama kapsamında gerçekleştirilir. Ancak bu tür
yazılımların
doğrulanmasında
mevcut
gözden
geçirmelere ek olarak izlenebilirlik, ek gözden
geçirmeler ve kapsama (coverage) analizleri
gerçekleştirilir. Ayrıca geliştirilen emniyet-kritik sistem
için de sistem emniyet analizleri yapılır. Şekil 2’de
emniyet-kritik yazılımların statik doğrulama yöntemleri
gösterilmiştir.
Kod
Gözden
Geçirme
Emniyet-kritik yazılımlarda, emniyet-kritik olmayan
yazılımların
statik
doğrulamasına
ek
olarak
izlenebilirlik, gereksinim kapsama (requirement
coverage) analizi ve test durumları gözden geçirmeleri
gerçekleştirilmelidir. Dinamik doğrulamada ise testlere
ek olarak yapısal kapsama (structural coverage) analizi
ve test durumları ile kaynak kod arasındaki
izlenebilirlik gerçekleştirilmelidir.
İzlenebilirliklerin
kurulması
emniyet-kritik
yazılımların geliştirilmesinde ayrı bir öneme sahiptir.
Tüm müşteri gereksinimlerinin yeterli bir şekilde
detaylandırılarak
sistem
gereksinimlerinin
oluşturulduğu,
sistem
gereksinimlerinin
detaylandırılarak bunlardan yazılım gereksinimlerinin
oluşturulduğu ancak izlenebilirlik ile sistematik olarak
doğrulanabilir. İzlenebilirlik gereksinim kapsaması için
gereklidir. Bununla birlikte tüm gereksinimlerin test
edildiğinin gösterilebilmesi için de test durumları ile
gereksinimler
arası
izlenebilirliğin
kurulması
gereklidir.
Test durumları ile kaynak kod arası kurulan
izlenebilirlik dinamik doğrulamada gerçekleştirilen
yapısal kapsama için gereklidir. Yapısal kapsama
analizleri ile emniyet-kritik yazılımın sınır değerlerinin
aşılması, uyarı-dikkat-ikaz bölgelerine girilmesi gibi
olası bütün çalışma durumlarına karşı test edilmesi
sağlanır.
Gereksinimlerden
kaynak
koda
doğru giden
izlenebilirliğe ileri yönde izlenebilirlik; kaynak koddan
gereksinimlere doğru olan izlenebilirliğe geri yönde
izlenebilirlik denir. Şekil 3’de izlenebilirlik yapısı,
görülmektedir.
Müşteri
Gereksinimleri
Statik
Doğrulama
Gereksinim
Gözden
Geçirme
Şekil 2: Emniyet-kritik yazılımlarda statik doğrulama
yöntemleri
İzlenebilirlik
Sistem
Gereksinimleri
Test
Durumları
Gereksinim
Kapsama
Yazılım
Gereksinimleri
Test Durumları
Gözden
Geçirme
Kaynak
Kod
İleri Yönde İzlenebilirlik
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
Şekil 3: Emniyet-kritik yazılımlarda izlenebilirlikler
Emniyet-kritik yazılımların doğrulanma sürecinde
diğer bir önemli konu da kapsama analizleridir. Bu tür
yazılımlarda iki tür kapsamaya bakılması gereklidir.
Gereksinim kapsaması statik doğrulamada, yapısal
kapsama ise dinamik doğrulamada gerçekleştirilir.
Şekil 4’de izlenebilirlik ve kapsama ilişkisi
gösterilmiştir. Şekilde görüldüğü gibi, her bir sistem ve
yazılım gereksinimini doğrulayacak en az bir test
durumunun yazıldığının analizinin yapılmasına
gereksinim kapsama denir. Böylelikle dinamik
doğrulamada
testler
gerçekleştirilirken
tüm
gereksinimleri doğrulayacak olan test durumlarının
mevcut olduğu gösterilir. Yapısal kapsamada ise
koşturulan test durumları ile kodun ne kadarının
çalıştırıldığı ve çalıştırılmayan kod parçasının olmadığı
doğrulanır. Yapısal kapsama analizleri ile kod
içerisindeki tüm satırların çalıştırılarak test edilmesi
sağlanır.
Sistem
Gereksinimleri
Gereksinim
Kapsama
Test
Durumları
Yazılım
Gereksinimleri
Yapısal
Kapsama
Kaynak
Kod
Şekil 4: İzlenebilirlik- kapsama ilişkisi
Statik ve dinamik doğrulamanın otomatikleştirilmesi ve
yazılım test araçlarının etkin bir şekilde kullanılması
büyük önem taşır. Bu araçlar, özellikle DO178B gibi
rehberler ve standartların öngördüğü doğrulama
faaliyetlerinin gerçekleştirilmesinde önemli kolaylıklar
sağlar.
Emniyet–kritik yazılımların doğrulama sürecinde ek
olarak gerçekleştirilen bir diğer işlem ise test
durumlarının gözden geçirilmesidir. Test durumlarını
gözden geçirmedeki amaç doğrulanacak olan
gereksinimlerin üretilen test durumu veya durumları ile
gerçekten
doğrulanıp
doğrulanmadığının
anlaşılmasıdır. Böylece her gereksinimin yeter sayıda
ve doğru yapıda test durumu ile doğrulanabileceği
garanti altına alınmaya çalışılır.
Emniyet-kritik yazılımların doğrulama sürecine
getirilen bu ek denetimler ile geliştirilen kritik
yazılımın hedeflenen tüm işlevleri doğru bir şekilde
yerine getirdiği, hedeflenenin dışında yazılımın
içerisinde fazladan kod parçacıklarının olmadığı ve
hedeflenen işlevlerin uygun bir yapıda test edildiği
doğrulanarak kayıt altına alınmış olur.
Ayrıca emniyet-kritik sistemler geliştirilirken yukarıda
değinilen yazılım doğrulama faaliyetlerinin yanında
sistem emniyeti çalışmaları yapılır.
3.1 Sistem Emniyeti Çalışmaları
Emniyet kritik sistemler geliştirilirken sistem emniyeti
ile ilgili çalışmalar projenin tasarım aşamasından
itibaren başlar ve projenin tüm hayat döngüsü boyunca
emniyet çalışmaları diğer süreçlere paralel olarak
devam eder.
Emniyet-kritik sistem geliştirilirken yapılan olası
hatalar sistemde kusurlar oluşmasına neden olur, bu
kusurlar sistemin başarısızlığa uğramasına neden
olabilir. Beklenmedik davranışlara neden olan bu
başarısızlıklar tehlikeli durumlara neden olur. Sonuçta
tehlikeli durumlar da kazalara yol açabilir. Bu nedenle
emniyet-kritik sistemler geliştirilirken doğrulama ve
geçerleme faaliyetlerine ek olarak fonksiyonel tehlike
analizi, hata modları ve etkileri analizi, hata ağacı
analizi, olay ağacı analizi, neden-sonuç analizi gibi
çeşitli analiz teknikleri de kullanılır.
Sistem emniyeti, geliştirilen sistemde hiçbir hatanın
olmaması veya olası hataların etkilerinin en aza
indirilerek insan, mal kaybı ve çevresel zararlara neden
olmayacak
şekilde
sistemin
geliştirilmesini
sağlamaktır.
Sistemin müşteriye tesliminden önce gerekli emniyeti
sağlamak için gerçekleştirilecek bazı etkinlikler
şunlardır:
•
•
•
•
•
Fonksiyonel Tehlike Analizi
Hata Modları ve Etkileri Analizi (FMEA)
Hata Modları ve Etkileri Kritiklik Analizi
(FMECA)
Hata Ağacı Analizi
Sistem Emniyet Değerlendirmesi
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
Emniyet çalışmaları kapsamında öncelikle sistem
fonksiyonları belirlenir. Bu fonksiyonlara ilişkin
potansiyel tehlikeler ve bunlara neden olabilecek olası
hatalar ve bunların etkileri fonksiyonel tehlike analizi
ve FMEA ile tespit edilip, hatalar türlerine göre
sınıflandırılır. Hatalar ayrıca emniyet seviyelerine göre
de sınıflandırılır. Bu hataların olma olasılıkları hata
ağacı analizleri ile hesaplanarak ilgili tablolara
kaydedilir. Bu hatalardan Tablo-1 veya Tablo-2’ de
örnek olarak gösterilen emniyet sınıfı tablolarında
belirtilen emniyet hedeflerini sağlayamayanları tespit
edilerek tehlike analizi tablolarına eklenir. Bu analizler
sonunda, sistem emniyeti değerlendirme raporu
hazırlanır. Raporda yer alan emniyet hedefini
sağlayamayan hataların önlenmesi için gerekli düzeltici
eylemlerin gerçekleştirilmesi sağlanır. Düzeltici
eylemler yapılırken gerektiğinde tasarım evresine geri
dönülerek tasarım değişikliğiyle, istenen emniyet hedefi
sağlanır. Böylece emniyet kritik yazılımların kullanımı
sırasında olası tehlikelerin ortaya çıkma olasılığı
sıfırlanamasa bile kabul edilebilir düzeye indirilmesi
amaçlanır. Bununla beraber emniyet hedefinin
sağlanamadığı
durumlarda,
mutlaka
önceden
tanımlanmış prosedürler, ikaz ışıkları ve sinyaller gibi
uyarıcılar kullanılarak gerekli önlemler alınır.
Geliştirilen emniyet-kritik sisteme göre analizler
sırasında kullanılacak emniyet seviyeleri farklılık
gösterir. Örnek olarak DO178B’ye göre havacılık
alanındaki emniyet-kritik yazılımlar için kullanılan
emniyet seviyeleri şu şekildedir[8]:
Tablo-1 Emniyet Seviyeleri (örnek)
Seviye
Emniyet Sınıfı
Seviye A Ölümcül
(Catastrophic)
Seviye B Kritik (Hazardous)
Seviye C Önemli (Major)
Seviye D Az Önemli (Minor)
Seviye E Etkisiz (No effect)
Emniyet Hedefi
<10-9
<10-7
<10-5
>10-5
-
Nükleer enerji alanında kullanılan emniyet seviyeleri
ise IEC 61226 standardına göre şu şekildedir:
Tablo-2 Emniyet Seviyeleri (örnek)
Seviye
Açıklama
Seviye A Can ve mal kaybı ile
çevresel hasara yol
açabilecek
nükleer
kaza
Seviye B A seviyesi kazaya
neden olabilecek kaza
Seviye C Nükleer kaza olmayıp,
yardımcı sistemlerde
meydana gelebilecek
kaza
Emniyet Hedefi
<10-8
<10-7
<10-5
4. Sonuç
Sonuç olarak, günümüzün gelişen Türkiye’sinin
yazılım sektörü şu an olmasa da yakın gelecekte yoğun
bir şekilde kara/hava/deniz platformlarında kullanılan
silah sistemlerinde, ulaşım araçları ve otomotiv
sektöründeki sistem kontrol ve yönetiminde, kimyasal
fabrika otomasyonlarında, biyomedikal cihazlarda,
hatta nükleer santral kontrol ve yönetiminde ve uzay
araçlarında emniyet-kritik yazılımlar geliştirmeye,
artan bir hızla devam edecektir. Bu yazılımlar doğası
gereği yüksek risk taşımaktadırlar. Bu nedenle
emniyet-kritik yazılımların doğrulanma süreci diğer
yazılımların
doğrulanma
sürecinden
farklılık
göstermelidir.
Bu çalışma kapsamında insan, ekipman ve çevre
açısından büyük önem taşıyan emniyet-kritik
yazılımların doğrulama sürecinde üzerinde önemle
durulması gereken noktalara ve sistem emniyeti
çalışmalarına değinilmiştir
5. Kaynaklar
[1] Sarıdoğan, M., E., “Yazılım Mühendisliği”,
Papatya yay., 2008
[2] Anderson, C., “Exploring the software Verification
and Validation Process with Focus on Efficient
Fault Detection”, Licentiate Thesis.Lund Institute
of Technology, 2003
[3] Amey, P., Chapman,R., “Static Verification and
Extreme Programming”, ACM SIGAda, 2003
[4] Bormann,J.,Fedeli,A.,Frank,R.Winkelmann,K.,
“Combined Static and Dynamic Verification”,
Research Report, FP6-IST-507219, Version 2Public Version, 31 March 2005
[5] IEEE Standard 1028, “Software Engineering Standard
Committee of The IEEE Computer Society”, IEEE
Standard 1028. IEEE Standard for Software review,
Institute of Electrical and Electronics Engineers Inc.,
New York, 1998
[6] Richard,
L.K.,
“Testing
Requirements”,
http://www.projectmangler.com/content/regular/art
20050516.htm, 2005
[7] Widera, M., “Why Testing Matters in Functional
Programming”, 7th Symposium on Trends in
Functional
Programming,
University
of
Nottingham, TFP 2006
[8] RTCA DO-178B “Software Considerations in
Airbone Systems and Equipment Certification”,
RTCA, 1992