DO-178C Hedef Gezgini
DO-178C'nin Ek A tablolarındaki 71 hedefi (objective) yazılım seviyesine (software level) göre süzer. Sahada çoğunlukla DAL diye anılan seviyeyi seçin; araç o seviyede hangi hedeflerin arandığını, hangilerinin bağımsızlıkla (independence) karşılanması gerektiğini ve kanıtın hangi yaşam döngüsü verisinde (software life cycle data) duracağını listeler.
- Hedef
- 71 / 71
- Bağımsızlıkla
- 30 hedef
- Veri öğesi
- 22 / 22
- Arıza durumu
- Katastrofik
Seviye A'da beklenen yaşam döngüsü verisi ve kontrol kategorileri (22 öğe)
- 11.1Yazılım sertifikasyon planı (PSAC)CC1
- 11.2Yazılım geliştirme planı (SDP)CC1
- 11.3Yazılım doğrulama planı (SVP)CC1
- 11.4Yazılım konfigürasyon yönetimi planı (SCMP)CC1
- 11.5Yazılım kalite güvencesi planı (SQAP)CC1
- 11.6Yazılım gereksinim standartlarıCC1
- 11.7Yazılım tasarım standartlarıCC1
- 11.8Kodlama standardıCC1
- 11.9Yazılım gereksinim verisiCC1
- 11.10Tasarım tanımıCC1
- 11.11Kaynak kodCC1
- 11.12Çalıştırılabilir nesne koduCC1
- 11.13Yazılım doğrulama durumları ve prosedürleriCC1
- 11.14Yazılım doğrulama sonuçlarıCC2
- 11.15Yaşam döngüsü ortam konfigürasyon indeksi (SECI)CC1
- 11.16Yazılım konfigürasyon indeksi (SCI)CC1
- 11.17Problem raporlarıCC2
- 11.18Konfigürasyon yönetimi kayıtlarıCC2
- 11.19Kalite güvencesi kayıtlarıCC2
- 11.20Yazılım başarı özeti (SAS)CC1
- 11.21İz verisi (geliştirme)CC1
- 11.21İz verisi (test)CC1
- 11.22PDI dosyasıCC1
CC1 veride değişiklik kontrolü ve problem raporlama dahil bütün konfigürasyon yönetimi faaliyetleri uygulanır; CC2 veride daha dar bir küme yeter. Ayrıntı: 10. Yazılım Konfigürasyon Yönetimi.
71 hedef listeleniyor
bağımsızlıkla gerekli aranmazTablo A-1Yazılım planlama süreci
Seviye A'da 7/7 hedef · Kitapta: 5. Yazılım Planlama
- A-1.1
Yaşam döngüsü süreçlerinin faaliyetleri tanımlı
Geliştirme süreçlerinde ve bütünleyici süreçlerde hangi işlerin yapılacağı, sistem gereksinimlerini ve yazılım seviyesini karşılayacak biçimde planlara yazılmıştır.
DO-178C §4.1.aPSACCC1SDPCC1SVPCC1SCMPCC1SQAPCC1
GerekliABCD - A-1.2
Yaşam döngüsü, süreç ilişkileri ve geçiş kriterleri tanımlı
Süreçlerin sırası, birbirini nasıl beslediği, geri bildirim yolları ve bir süreçten ötekine hangi koşulla geçileceği bellidir.
DO-178C §4.1.bPSACCC1SDPCC1SVPCC1SCMPCC1SQAPCC1
GerekliABCD - A-1.3
Yaşam döngüsü ortamı seçilmiş ve tanımlı
Geliştirme ve doğrulamada kullanılacak yöntemler, araçlar, derleyici ve test ortamı seçilmiş, planlarda tanımlanmıştır.
DO-178C §4.1.cPSACCC1SDPCC1SVPCC1SCMPCC1SQAPCC1
GerekliABCD - A-1.4
Ek hususlar ele alınmış
Araç kalifikasyonu, önceden geliştirilmiş yazılım ya da alternatif yöntem gibi projeye özgü konular planlarda karşılığını bulmuştur.
DO-178C §4.1.dPSACCC1SDPCC1SVPCC1SCMPCC1SQAPCC1
GerekliABCD - A-1.5
Yazılım geliştirme standartları tanımlı
Gereksinim, tasarım ve kodlama standartları, geliştirilecek yazılımın emniyet beklentileriyle tutarlı biçimde yazılmıştır.
DO-178C §4.1.eYazılım gereksinim standartlarıCC1Yazılım tasarım standartlarıCC1Kodlama standardıCC1
GerekliABCD - A-1.6
Planlar DO-178C ile uyumlu
Planların standardın beklentilerini karşıladığı gözden geçirilerek gösterilmiş, sonuç kayda geçirilmiştir.
DO-178C §4.1.fYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-1.7
Planların geliştirilmesi ve revizyonu eşgüdümlü
Planlar birbiriyle tutarlıdır; biri değiştiğinde ötekilere etkisi izlenir ve birlikte güncellenir.
DO-178C §4.1.gYazılım doğrulama sonuçlarıCC2
GerekliABCD
Tablo A-2Yazılım geliştirme süreçleri
Seviye A'da 7/7 hedef · Kitapta: 6. Yazılım Gereksinimleri, 7. Yazılım Tasarımı, 8. Kodlama ve Entegrasyon
- A-2.1
Yüksek seviyeli gereksinimler geliştirilmiş
Yazılıma tahsis edilen sistem gereksinimlerinden, yazılımın ne yapacağını anlatan yüksek seviyeli gereksinimler üretilmiştir.
DO-178C §5.1.1.aYazılım gereksinim verisiCC1İz verisi (geliştirme)CC1
GerekliABCD - A-2.2
Türetilmiş yüksek seviyeli gereksinimler tanımlanmış ve sistem süreçlerine iletilmiş
Bir sistem gereksinimine doğrudan izlenemeyen gereksinimler ayrıca belirlenir; emniyet değerlendirmesi dahil sistem süreçlerine bildirilir.
DO-178C §5.1.1.bYazılım gereksinim verisiCC1
GerekliABCD - A-2.3
Yazılım mimarisi geliştirilmiş
Yüksek seviyeli gereksinimlerden bileşenleri, arayüzleri, veri akışını ve kontrol akışını gösteren mimari çıkarılmıştır.
DO-178C §5.2.1.aTasarım tanımıCC1
GerekliABCD - A-2.4
Düşük seviyeli gereksinimler geliştirilmiş
Kaynak kodun başka bilgiye gerek kalmadan yazılabileceği ayrıntıdaki gereksinimler üretilmiştir.
DO-178C §5.2.1.aTasarım tanımıCC1İz verisi (geliştirme)CC1
GerekliABCD - A-2.5
Türetilmiş düşük seviyeli gereksinimler tanımlanmış ve sistem süreçlerine iletilmiş
Tasarım kararlarından doğan, üst gereksinime izlenemeyen gereksinimler emniyet değerlendirmesi dahil sistem süreçlerine bildirilir.
DO-178C §5.2.1.bTasarım tanımıCC1
GerekliABCD - A-2.6
Kaynak kod geliştirilmiş
Düşük seviyeli gereksinimlerden ve mimariden, kodlama standardına uyan kaynak kod yazılmıştır.
DO-178C §5.3.1.aKaynak kodCC1İz verisi (geliştirme)CC1
GerekliABCD - A-2.7
Çalıştırılabilir nesne kodu ve varsa PDI dosyaları üretilmiş, hedef bilgisayara yüklenmiş
Kaynak kod derlenip bağlanmış; ortaya çıkan imaj ve parametre verisi dosyaları donanım/yazılım entegrasyonu için hedef bilgisayara yüklenmiştir.
DO-178C §5.4.1.aÇalıştırılabilir nesne koduCC1PDI dosyasıCC1
GerekliABCD
Tablo A-3Gereksinim süreci çıktılarının doğrulanması
Seviye A'da 7/7 hedef, 3 hedef bağımsızlıkla · Kitapta: 9. Yazılım Doğrulama
- A-3.1
Yüksek seviyeli gereksinimler sistem gereksinimlerine uygun
Yazılıma tahsis edilen sistem işlevleri gereksinimlerde doğru karşılanmıştır; türetilmiş gereksinimlerin neden var olduğu bellidir.
DO-178C §6.3.1.aYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-3.2
Yüksek seviyeli gereksinimler doğru ve tutarlı
Her gereksinim açık, belirsizlikten uzak ve yeterince ayrıntılıdır; gereksinimler birbiriyle çelişmez.
DO-178C §6.3.1.bYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-3.3
Yüksek seviyeli gereksinimler hedef bilgisayarla uyumlu
Gereksinimler donanımın ve işletim ortamının özellikleriyle, örneğin yanıt süreleri ve giriş/çıkış donanımıyla çatışmaz.
DO-178C §6.3.1.cYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-3.4
Yüksek seviyeli gereksinimler doğrulanabilir
Her gereksinimin sağlandığı test, analiz ya da gözden geçirmeyle gösterilebilecek biçimde yazılmıştır.
DO-178C §6.3.1.dYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-3.5
Yüksek seviyeli gereksinimler standartlara uygun
Gereksinimler yazılım gereksinim standartlarına göre yazılmıştır; sapma varsa gerekçesi kayıtlıdır.
DO-178C §6.3.1.eYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-3.6
Yüksek seviyeli gereksinimler sistem gereksinimlerine izlenebilir
Yazılıma tahsis edilen her sistem gereksinimi, yüksek seviyeli gereksinimlerde karşılığını bulmuştur.
DO-178C §6.3.1.fYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-3.7
Algoritmalar doğru
Gereksinimlerde önerilen algoritmaların doğruluğu ve davranışı, özellikle süreksizlik noktalarında doğrulanmıştır.
DO-178C §6.3.1.gYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD
Tablo A-4Tasarım süreci çıktılarının doğrulanması
Seviye A'da 13/13 hedef, 6 hedef bağımsızlıkla · Kitapta: 9. Yazılım Doğrulama, 21. Yazılım Bölümlemesi
- A-4.1
Düşük seviyeli gereksinimler yüksek seviyeli gereksinimlere uygun
Düşük seviyeli gereksinimler üst gereksinimleri eksiksiz karşılar; türetilmiş olanların tasarım gerekçesi bellidir.
DO-178C §6.3.2.aYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-4.2
Düşük seviyeli gereksinimler doğru ve tutarlı
Her düşük seviyeli gereksinim açık ve belirsizlikten uzaktır; gereksinimler birbiriyle çelişmez.
DO-178C §6.3.2.bYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-4.3
Düşük seviyeli gereksinimler hedef bilgisayarla uyumlu
Gereksinimler donanımın özellikleriyle; özellikle veri yolu yükü, yanıt süreleri ve giriş/çıkış donanımıyla çatışmaz.
DO-178C §6.3.2.cYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-4.4
Düşük seviyeli gereksinimler doğrulanabilir
Her düşük seviyeli gereksinimin sağlandığı test, analiz ya da gözden geçirmeyle gösterilebilir.
DO-178C §6.3.2.dYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-4.5
Düşük seviyeli gereksinimler standartlara uygun
Tasarım, yazılım tasarım standartlarına göre yapılmıştır; sapma varsa gerekçesi kayıtlıdır.
DO-178C §6.3.2.eYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-4.6
Düşük seviyeli gereksinimler yüksek seviyeli gereksinimlere izlenebilir
Her yüksek seviyeli gereksinim ve türetilmiş gereksinim, düşük seviyeli gereksinimlerde karşılığını bulmuştur.
DO-178C §6.3.2.fYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-4.7
Algoritmalar doğru
Tasarımda kullanılan algoritmaların doğruluğu ve davranışı, özellikle süreksizlik noktalarında doğrulanmıştır.
DO-178C §6.3.2.gYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-4.8
Yazılım mimarisi yüksek seviyeli gereksinimlerle uyumlu
Mimari üst gereksinimlerle çelişmez; bölümleme gibi sistem bütünlüğünü koruyan işlevlerde bu özellikle aranır.
DO-178C §6.3.3.aYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-4.9
Yazılım mimarisi tutarlı
Bileşenler arasındaki veri akışı ve kontrol akışı ilişkileri doğru kurulmuştur.
DO-178C §6.3.3.bYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-4.10
Yazılım mimarisi hedef bilgisayarla uyumlu
Mimari; başlatma, eşzamansız işleyiş, eşzamanlama ve kesmeler bakımından donanımla çatışmaz.
DO-178C §6.3.3.cYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-4.11
Yazılım mimarisi doğrulanabilir
Mimari, sınırı belirsiz özyineleme gibi doğrulanması mümkün olmayan yapılar içermez.
DO-178C §6.3.3.dYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-4.12
Yazılım mimarisi standartlara uygun
Mimari, tasarım standartlarındaki kısıtlara (örneğin karmaşıklık sınırlarına) uyar; sapma varsa gerekçesi kayıtlıdır.
DO-178C §6.3.3.eYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-4.13
Yazılım bölümleme bütünlüğü doğrulanmış
Bölümleme kullanılıyorsa, bir bölümün ötekini bellek ya da zaman yönünden etkileyemediği gösterilmiştir.
DO-178C §6.3.3.fYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD
Tablo A-5Kodlama ve entegrasyon çıktılarının doğrulanması
Seviye A'da 9/9 hedef, 5 hedef bağımsızlıkla · Kitapta: 9. Yazılım Doğrulama, 22. Konfigürasyon Verisi
- A-5.1
Kaynak kod düşük seviyeli gereksinimlere uygun
Kod, düşük seviyeli gereksinimleri doğru ve eksiksiz gerçekleştirir; gereksinimlerde olmayan işlev içermez.
DO-178C §6.3.4.aYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-5.2
Kaynak kod yazılım mimarisine uygun
Kod, mimaride tanımlanan veri akışına ve kontrol akışına uyar.
DO-178C §6.3.4.bYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-5.3
Kaynak kod doğrulanabilir
Kod doğrulanamayan ifade ya da yapı içermez; test edilebilmesi için değiştirilmesi gerekmez.
DO-178C §6.3.4.cYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-5.4
Kaynak kod standartlara uygun
Kodlama standardına, karmaşıklık kısıtları dahil uyulmuştur; sapma varsa gerekçesi kayıtlıdır.
DO-178C §6.3.4.dYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-5.5
Kaynak kod düşük seviyeli gereksinimlere izlenebilir
Kodun her parçası bir düşük seviyeli gereksinime bağlanır; gereksinimlerin tamamı kodda karşılığını bulmuştur.
DO-178C §6.3.4.eYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-5.6
Kaynak kod doğru ve tutarlı
Yığın ve bellek kullanımı, taşma, kaynak çekişmesi, en kötü durum yürütme süresi, istisna işleme ve başlatılmamış değişken gibi konularda kodun doğruluğu gözden geçirme ve analizle gösterilmiştir.
DO-178C §6.3.4.fYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-5.7
Entegrasyon sürecinin çıktısı tam ve doğru
Derleme, bağlama ve yükleme verileri ile bellek haritası gözden geçirilmiş; hatalı adres, bellek çakışması ve eksik bileşen aranmıştır.
DO-178C §6.3.5.aYazılım doğrulama sonuçlarıCC2
GerekliABCD - A-5.8
PDI dosyası doğru ve eksiksiz
Dosya, yüksek seviyeli gereksinimlerde tanımlı yapıya uyar; her öğenin değeri doğrudur ve öbür öğelerle tutarlıdır.
DO-178C §6.6.aYazılım doğrulama durumları ve prosedürleriCC1Yazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-5.9
PDI dosyasının doğrulaması tamamlanmış
Dosyadaki bütün öğeler doğrulama sırasında ele alınmıştır; bakılmadan geçilen öğe kalmamıştır.
DO-178C §6.6.bYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD
Tablo A-6Entegrasyon süreci çıktılarının test edilmesi
Seviye A'da 5/5 hedef, 2 hedef bağımsızlıkla · Kitapta: 9. Yazılım Doğrulama: Testin rolü
- A-6.1
Çalıştırılabilir nesne kodu yüksek seviyeli gereksinimlere uygun
Normal aralıktaki test durumlarıyla, kodun yüksek seviyeli gereksinimleri karşıladığı gösterilmiştir.
DO-178C §6.4.aYazılım doğrulama durumları ve prosedürleriCC1Yazılım doğrulama sonuçlarıCC2İz verisi (test)CC1
GerekliABCD - A-6.2
Çalıştırılabilir nesne kodu yüksek seviyeli gereksinimlere göre gürbüz
Geçersiz girdilerde ve anormal koşullarda kodun yüksek seviyeli gereksinimlerin öngördüğü biçimde davrandığı test edilmiştir.
DO-178C §6.4.bYazılım doğrulama durumları ve prosedürleriCC1Yazılım doğrulama sonuçlarıCC2İz verisi (test)CC1
GerekliABCD - A-6.3
Çalıştırılabilir nesne kodu düşük seviyeli gereksinimlere uygun
Normal aralıktaki test durumlarıyla, kodun düşük seviyeli gereksinimleri karşıladığı gösterilmiştir.
DO-178C §6.4.cYazılım doğrulama durumları ve prosedürleriCC1Yazılım doğrulama sonuçlarıCC2İz verisi (test)CC1
BağımsızlıklaABCD - A-6.4
Çalıştırılabilir nesne kodu düşük seviyeli gereksinimlere göre gürbüz
Geçersiz girdilerde ve anormal koşullarda kodun düşük seviyeli gereksinimlerin öngördüğü biçimde davrandığı test edilmiştir.
DO-178C §6.4.dYazılım doğrulama durumları ve prosedürleriCC1Yazılım doğrulama sonuçlarıCC2İz verisi (test)CC1
BağımsızlıklaABCD - A-6.5
Çalıştırılabilir nesne kodu hedef bilgisayarla uyumlu
Kod hedef donanımda koşturulmuş; donanım/yazılım entegrasyonuna özgü hatalar aranmıştır.
DO-178C §6.4.eYazılım doğrulama durumları ve prosedürleriCC1Yazılım doğrulama sonuçlarıCC2
GerekliABCD
Tablo A-7Doğrulama süreci sonuçlarının doğrulanması
Seviye A'da 9/9 hedef, 9 hedef bağımsızlıkla · Kitapta: 9. Yazılım Doğrulama: Doğrulamanın doğrulanması
- A-7.1
Test prosedürleri doğru
Test durumları, beklenen sonuçlarıyla birlikte test prosedürlerine doğru aktarılmıştır.
DO-178C §6.4.5.bYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-7.2
Test sonuçları doğru, tutarsızlıklar açıklanmış
Gerçekleşen sonuçlar beklenenle karşılaştırılmış; aradaki her fark açıklanmıştır.
DO-178C §6.4.5.cYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-7.3
Yüksek seviyeli gereksinimlerin test kapsamı sağlanmış
Her yüksek seviyeli gereksinim için normal aralık ve gürbüzlük test durumları vardır; eksik kalan gereksinim giderilmiştir.
DO-178C §6.4.4.aYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-7.4
Düşük seviyeli gereksinimlerin test kapsamı sağlanmış
Her düşük seviyeli gereksinim için normal aralık ve gürbüzlük test durumları vardır; eksik kalan gereksinim giderilmiştir.
DO-178C §6.4.4.bYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-7.5
Yapısal kapsam sağlanmış: MC/DC
Her koşulun karar sonucunu tek başına değiştirebildiği, gereksinim tabanlı testlerin koşusuyla gösterilmiştir.
DO-178C §6.4.4.cYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-7.6
Yapısal kapsam sağlanmış: karar kapsama
Gereksinim tabanlı testlerde her karar hem doğru hem yanlış sonuçlanmış, her giriş ve çıkış noktası çalışmıştır.
DO-178C §6.4.4.cYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-7.7
Yapısal kapsam sağlanmış: satır kapsama
Gereksinim tabanlı testlerde kodun her satırı en az bir kez yürütülmüştür.
DO-178C §6.4.4.cYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-7.8
Yapısal kapsam sağlanmış: veri ve kontrol bağlaşımı
Bileşenler arasındaki veri ve kontrol bağımlılıklarının gereksinim tabanlı testlerle çalıştırıldığı analizle gösterilmiştir.
DO-178C §6.4.4.dYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD - A-7.9
Kaynak koda izlenemeyen ek kod doğrulanmış
Derleyicinin ürettiği, kaynak kod satırına doğrudan izlenemeyen nesne kodunun doğruluğu ayrıca gösterilmiştir.
DO-178C §6.4.4.cYazılım doğrulama sonuçlarıCC2
BağımsızlıklaABCD
Tablo A-8Yazılım konfigürasyon yönetimi süreci
Seviye A'da 6/6 hedef · Kitapta: 10. Yazılım Konfigürasyon Yönetimi
- A-8.1
Konfigürasyon öğeleri tanımlanmış
Her yaşam döngüsü verisi benzersiz bir kimlik ve sürümle etiketlenmiştir.
DO-178C §7.1.aKonfigürasyon yönetimi kayıtlarıCC2
GerekliABCD - A-8.2
Temel çizgiler ve izlenebilirlik kurulmuş
Onaylı temel çizgiler tanımlanmıştır; bir temel çizginin öncekinden nasıl türediği izlenebilir.
DO-178C §7.1.bSCICC1Konfigürasyon yönetimi kayıtlarıCC2
GerekliABCD - A-8.3
Problem raporlama, değişiklik kontrolü, değişiklik gözden geçirmesi ve konfigürasyon durum muhasebesi kurulmuş
Uyumsuzluklar kayda geçer; değişiklikler yetkiyle yapılır, etkisi gözden geçirilir ve her öğenin güncel durumu raporlanabilir.
DO-178C §7.1.c–fProblem raporlarıCC2Konfigürasyon yönetimi kayıtlarıCC2
GerekliABCD - A-8.4
Arşivleme, geri getirme ve sürüm teslimi kurulmuş
Veri korunarak saklanır ve gerektiğinde aynı yazılımı yeniden üretecek biçimde geri getirilebilir; yalnızca yetkilendirilmiş sürümler teslim edilir.
DO-178C §7.1.gKonfigürasyon yönetimi kayıtlarıCC2
GerekliABCD - A-8.5
Yazılım yükleme kontrolü kurulmuş
Çalıştırılabilir nesne kodunun ve PDI dosyalarının hedefe doğru parça numarasıyla ve bozulmadan yüklendiği güvence altındadır.
DO-178C §7.1.hKonfigürasyon yönetimi kayıtlarıCC2
GerekliABCD - A-8.6
Yaşam döngüsü ortamının kontrolü kurulmuş
Yazılımı üretmek ve doğrulamak için kullanılan araçlar tanımlıdır, kontrol altındadır ve ortam yeniden kurulabilir.
DO-178C §7.1.iSECICC1Konfigürasyon yönetimi kayıtlarıCC2
GerekliABCD
Tablo A-9Yazılım kalite güvencesi süreci
Seviye A'da 5/5 hedef, 5 hedef bağımsızlıkla · Kitapta: 11. Yazılım Kalite Güvencesi
- A-9.1
Planlar ve standartlar geliştirilmiş, DO-178C ile uyumu ve tutarlılığı gözden geçirilmiş
Kalite güvencesi, planların ve standartların yazıldığına ve hem standartla hem birbiriyle tutarlılığının gözden geçirildiğine dair güvence elde etmiştir.
DO-178C §8.1.aKalite güvencesi kayıtlarıCC2
BağımsızlıklaABCD - A-9.2
Süreçler onaylı planlara uygun yürüyor
Kalite güvencesi, işlerin planlarda yazıldığı gibi yapıldığını denetleyerek doğrular; sapmalar kayda geçer ve izlenir.
DO-178C §8.1.bKalite güvencesi kayıtlarıCC2
BağımsızlıklaABCD - A-9.3
Süreçler onaylı standartlara uygun yürüyor
Kalite güvencesi, gereksinim, tasarım ve kodlama standartlarına uyulduğunu denetleyerek doğrular.
DO-178C §8.1.bKalite güvencesi kayıtlarıCC2
BağımsızlıklaABCD - A-9.4
Geçiş kriterleri sağlanmış
Bir süreçten ötekine, planlarda tanımlı geçiş kriterleri karşılanarak geçildiği denetlenmiştir.
DO-178C §8.1.cKalite güvencesi kayıtlarıCC2
BağımsızlıklaABCD - A-9.5
Yazılım uygunluk gözden geçirmesi yapılmış
Teslimden önce, yaşam döngüsü verisinin tam olduğu ve çalıştırılabilir nesne kodunun bu veriden yeniden üretilebildiği gözden geçirilmiştir.
DO-178C §8.1.dKalite güvencesi kayıtlarıCC2
BağımsızlıklaABCD
Tablo A-10Sertifikasyon irtibatı süreci
Seviye A'da 3/3 hedef · Kitapta: 12. Sertifikasyon İrtibatı
- A-10.1
Başvuru sahibi ile sertifikasyon otoritesi arasında iletişim ve ortak anlayış kurulmuş
Yazılımın nasıl geliştirileceği otoriteyle erken ve düzenli paylaşılır; beklentiler iki tarafta aynı anlaşılır.
DO-178C §9.aPSACCC1
GerekliABCD - A-10.2
Uyum yöntemi önerilmiş, PSAC üzerinde mutabakat sağlanmış
Hedeflerin nasıl karşılanacağı PSAC ile otoriteye sunulmuş ve plan üzerinde anlaşılmıştır.
DO-178C §9.bPSACCC1
GerekliABCD - A-10.3
Uyum kanıtı sunulmuş
Hedeflerin karşılandığı, yazılım başarı özeti ve konfigürasyon indeksiyle otoriteye gösterilmiştir.
DO-178C §9.cSASCC1SCICC1
GerekliABCD
Nasıl kullanılır?
- Seviyeyi seçin. A'dan E'ye beş düğme vardır; altlarında seviyenin bağlı olduğu en ağır arıza durumu (failure condition) sınıfı yazar. Sayaçlar o seviyedeki hedef sayısını, bağımsızlıkla karşılanacak hedefleri ve üretilecek veri öğelerini verir.
- Listeyi daraltın. Süreç düğmeleri Ek A'nın on tablosudur (A-1 … A-10); yanlarındaki sayı o tabloda seçili seviyede kaç hedefin arandığını gösterir. "Yalnızca bağımsızlık isteyenler" doğrulama ekibinin kimin neye bakamayacağını planlarken, arama kutusu belirli bir konuyu (izlenebilirlik, kapsam, PDI) ararken işe yarar.
- İki seviyeyi karşılaştırın. "Karşılaştır" listesinden ikinci bir seviye seçildiğinde her hedef, o seviyeye göre yeni hedef, bağımsızlık eklenir, düşer ya da bağımsızlık kalkar diye etiketlenir. "Yalnızca farklar" ile bir seviye değişikliğinin getirdiği ya da götürdüğü iş tek listede kalır.
- Satırı okuyun.
A-3.1, Tablo A-3'ün birinci hedefidir. Kalın satır hedefin özeti, altındaki cümle neyin gösterilmesi gerektiğidir. Onun altında hedefin tanımlandığı DO-178C bölümü, kanıtın yazıldığı veri ve o verinin seçili seviyedeki kontrol kategorisi (control category, CC1 ya da CC2) yer alır. Sağdaki dört hücre hedefin her seviyedeki durumudur. - Dışa aktarın. CSV, listelenen hedefleri boş "Uyum kanıtı" ve "Durum" sütunlarıyla verir; uyum matrisinin iskeleti olarak kullanılabilir. Bağlantı, seçili seviyeyi ve süzgeçleri taşır.
Seviye arttıkça hedefler nasıl artar?
Yazılım seviyesini yazılım ekibi seçmez; yazılımın katkıda bulunabileceği en ağır arıza durumuna göre sistem emniyet değerlendirmesinde belirlenir. Seviye yükseldikçe iki şey birlikte büyür: gösterilmesi gereken hedeflerin sayısı ve bunlardan, ürünü geliştiren kişiden başka birinin bakması gerekenlerin sayısı.
- Bağımsızlıkla karşılanan hedef
- Bağımsızlık aranmayan hedef
Artış düzgün değildir; her basamakta başka bir şey eklenir:
- Seviye D (26 hedef): yazılım dışarıdan görülür. Yüksek seviyeli gereksinimler yazılır ve gözden geçirilir, çalıştırılabilir nesne kodu bu gereksinimlere göre test edilir, her gereksinimin test edildiği gösterilir. Konfigürasyon yönetimi ve sertifikasyon irtibatı hedeflerinin tamamı, kalite güvencesinin iki hedefi bu seviyede de aranır. Düşük seviyeli gereksinimler, kaynak kod ve bunların doğrulanması hedef olarak yer almaz; yapısal kapsam istenmez.
- D'den C'ye (+36 hedef): yazılımın içi açılır. En büyük sıçrama buradadır. Düşük seviyeli gereksinimler ve kaynak kod geliştirme hedefi olur; tasarımın ve kodun gözden geçirilmesi, düşük seviyeli gereksinimlere dayalı test, satır kapsama ile veri ve kontrol bağlaşımı analizi eklenir. Planlama ve kalite güvencesi tabloları tamamlanır: standartlar, geçiş kriterleri, planların uyumu.
- C'den B'ye (+7 hedef, +13 bağımsızlık): ikinci göz gelir. Hedef sayısı az artar: gereksinimlerin ve mimarinin hedef bilgisayarla uyumu, düşük seviyeli gereksinimlerin, mimarinin ve kodun doğrulanabilirliği ve karar kapsama. Asıl değişiklik bağımsızlıktadır: doğrulama hedeflerinde ilk kez burada aranır. Gereksinimlerin bir üst seviyeye uygunluğu ve doğruluğu, algoritmalar, kodun düşük seviyeli gereksinimlere uygunluğu, parametre verisinin doğrulanması, düşük seviyeli gereksinim testleri ve yapısal kapsam artık yazarın kendisine bırakılmaz.
- B'den A'ya (+2 hedef, +12 bağımsızlık): en ince elek. Eklenen iki hedef değiştirilmiş koşul/karar kapsama (MC/DC) ile kaynak koda izlenemeyen nesne kodunun doğrulanmasıdır. Bağımsızlık mimariye, kodun mimariye uygunluğuna ve doğruluğuna, gürbüzlük testine, test prosedürlerine, test sonuçlarına ve gereksinim test kapsamına yayılır.
Aynı örüntü hedef hedef aşağıdadır. Seviye D satırı seyrektir; C'de çoğu sütun dolar, B ve A'da halkalar dolu daireye döner.
- Bağımsızlıkla karşılanır
- Karşılanır, bağımsızlık aranmaz
- O seviyede aranmaz
| Tablo | Süreç | Seviye D | Seviye C | Seviye B | Seviye A |
|---|---|---|---|---|---|
| A-1 | Yazılım planlama süreci | 2 | 7 | 7 | 7 |
| A-2 | Yazılım geliştirme süreçleri | 4 | 7 | 7 | 7 |
| A-3 | Gereksinim süreci çıktılarının doğrulanması | 3 | 6 | 7bağımsızlıkla: 3 | 7bağımsızlıkla: 3 |
| A-4 | Tasarım süreci çıktılarının doğrulanması | 1 | 9 | 13bağımsızlıkla: 3 | 13bağımsızlıkla: 6 |
| A-5 | Kodlama ve entegrasyon çıktılarının doğrulanması | 1 | 8 | 9bağımsızlıkla: 3 | 9bağımsızlıkla: 5 |
| A-6 | Entegrasyon süreci çıktılarının test edilmesi | 3 | 5 | 5bağımsızlıkla: 1 | 5bağımsızlıkla: 2 |
| A-7 | Doğrulama süreci sonuçlarının doğrulanması | 1 | 6 | 7bağımsızlıkla: 3 | 9bağımsızlıkla: 9 |
| A-8 | Yazılım konfigürasyon yönetimi süreci | 6 | 6 | 6 | 6 |
| A-9 | Yazılım kalite güvencesi süreci | 2bağımsızlıkla: 2 | 5bağımsızlıkla: 5 | 5bağımsızlıkla: 5 | 5bağımsızlıkla: 5 |
| A-10 | Sertifikasyon irtibatı süreci | 3 | 3 | 3 | 3 |
| Toplam | 26bağımsızlıkla: 2 | 62bağımsızlıkla: 5 | 69bağımsızlıkla: 18 | 71bağımsızlıkla: 30 |
Sayılar neyi söylemez?
- Hedef sayısı iş yükünün ölçüsü değildir. B ile A arasında yalnızca iki hedef vardır, ama biri MC/DC'dir ve tek başına aylar tutabilir. Karar yapılarında ne istediğini görmek için MC/DC test seti aracına bakabilirsiniz.
- Bağımsızlık kişi düzeyindedir, bölüm düzeyinde değil. Doğrulayanın, doğruladığı ürünün yazarı olmaması yeter; ayrı bir şirket ya da ekip gerekmez. Ayrıntı kitabın bağımsızlık bölümündedir.
- Konfigürasyon yönetiminde hedefler değil, sıkılık değişir. Tablo A-8'in altı hedefi her seviyede aynıdır; seviye düştükçe gevşeyen şey, verinin hangi kontrol kategorisinde yönetildiğidir. Araçtaki "beklenen yaşam döngüsü verisi" listesi bunu seviyeye göre gösterir.
- Hedef olmaması, işin yapılmadığı anlamına gelmez. Seviye D'de kaynak kod elbette yazılır; standart yalnızca kodun ve tasarımın ayrıntısına ilişkin kanıt istemez. Seviye E de bir muafiyet değil, emniyet değerlendirmesiyle gösterilmesi ve otoritece teyit edilmesi gereken bir sonuçtur.
Simgeler ve terimler
- Dolu daire hedefin bağımsızlıkla karşılanması gerektiğini, halka hedefin arandığını ama bağımsızlık istenmediğini, kısa çizgi hedefin o seviyede aranmadığını gösterir. İşaretler standardın tablolarındaki dolu ve boş dairelerin karşılığıdır.
- CC1 ve CC2, verinin konfigürasyon yönetiminde ne kadar sıkı kontrol edileceğini söyler. CC1 veride değişiklik kontrolü ve problem raporlama dahil bütün faaliyetler uygulanır; CC2 veri de kimliklendirilir, korunur ve saklanır, ama her düzeltmesi için resmî değişiklik süreci aranmaz.
- DAL sistem tarafının terimidir. Geliştirme güvence seviyesi (development assurance level) fonksiyona ve öğeye atanır; yazılım öğesine atanan seviye DO-178C'de yazılım seviyesi adını alır. Araçtaki A–E harfleri bu seviyedir.
Kapsam ve sınırlamalar
- Hedef özetleri ve açıklamalar bu site için yazılmıştır; standardın metni ya da çevirisi değildir. Hangi hedefin hangi seviyede arandığı, bağımsızlık, bölüm atıfları ve kontrol kategorileri Ek A tablolarıyla karşılaştırılmıştır; yine de bağlayıcı olan DO-178C / ED-12C metnidir.
- Araç yalnızca DO-178C'nin kendi tablolarını kapsar. Model tabanlı geliştirme (DO-331), nesne yönelimli teknoloji (DO-332) ve biçimsel yöntemler (DO-333) kullanan projelerde ilgili ek, bu tablolara hedef ekler ya da bazılarını değiştirir. Araç kalifikasyonunun hedefleri de ayrıdır ve DO-330'da araç kalifikasyon seviyesine göre düzenlenmiştir.
- Liste neyin gösterileceğini söyler, nasıl gösterileceğini değil. Hedeflere götüren faaliyetler projenin planlarında tanımlanır ve sertifikasyon otoritesiyle yazılım sertifikasyon planı üzerinden kararlaştırılır.
- Tablolardaki kontrol kategorileri asgaridir; proje bir veriyi daha sıkı yönetmeyi seçebilir, daha gevşek yönetemez.