SVP Şablonu ve Yazım Rehberi

Yazılım doğrulama planı (Software Verification Plan, SVP), seviyede geçerli doğrulama hedeflerinin (objective) hangi gözden geçirme (review), analiz ve testle, kim tarafından, hangi ortamda karşılanacağını ve kanıtın hangi kayıtta duracağını tanımlar. Okurları doğrulama ve geliştirme ekipleri, kalite güvencesi (quality assurance) ve denetimde sertifikasyon otoritesidir (certification authority). Tipik olarak doğrulama sorumlusu yazar; geliştirme sorumlusu, konfigürasyon yönetimi (configuration management) ve kalite güvencesi gözden geçirir, proje yönetimi onaylar. Plan, planlama sürecinde, yazılım sertifikasyon planıyla (Plan for Software Aspects of Certification, PSAC) birlikte ve ilk katılım aşaması (Stage of Involvement, SOI) denetimi olan SOI-1'den önce yazılır.

Planların neden yazıldığı 5. Yazılım Planlama bölümünde, doğrulamanın kendisi 9. Yazılım Doğrulama bölümünde, ortak kurallar genel bakış sayfasında anlatılır; bu sayfa SVP'nin nasıl yazılacağına odaklanır.

Bir bakışta

Özellik	Değer
DO-178C maddesi	§11.3
İlgili Ek A hedefleri	A-1 #1, #2, #3, #4 (çıktısıdır); A-3 … A-7 (karşılanma yöntemini tarif eder)
Beklendiği seviyeler	A, B, C, D
Kontrol kategorisi	CC1 (A, B); CC2 (C, D)
Otoriteye	Denetimde gösterilir
Sahibi	Doğrulama sorumlusu
İlgili SOI	SOI-1; uygulaması SOI-2 … SOI-4'te denetlenir

Şablonu nasıl kullanmalı?

Bölümleri sırayla doldurmaya başlamayın. Önce Ek A'nın A-3 … A-7 tablolarını yazılım seviyenize göre süzün ve kalan her hedef için "hangi yöntem, kim, hangi kayıt" sorusunu yanıtlayın; şablonun bölümleri bu yanıtları yerleştirmek için birer kutudur. Başlıklar kurumunuzun düzenine göre değişebilir; uyum tablosundaki her maddenin bir yeri olması yeter. Projede uygulanmayan bir bölümü silmeyin, gerekçesiyle "uygulanmaz" yazın.

Önerilen içindekiler

Ortak ön bölümler (belge kimliği, onaylar, revizyon geçmişi, referanslar, kısaltmalar ve tanımlar) genel bakış sayfasında anlatılır ve burada tekrarlanmaz.

1 Amaç ve kapsam
  1.1 Kapsanan yazılım, seviye ve konfigürasyonlar
  1.2 İlgili belgeler ve planın sınırları
2 Doğrulama organizasyonu
  2.1 Roller ve sorumluluklar
  2.2 Diğer süreçlerle arayüzler
3 Bağımsızlık
  3.1 Bağımsızlık aranan hedefler
  3.2 Bağımsızlığın sağlanması ve kaydı
4 Doğrulama yöntemleri
  4.1 Gözden geçirmeler ve kontrol listeleri
  4.2 Analizler
  4.3 Test durumu seçimi
  4.4 Test seviyeleri ve ortam ataması
  4.5 Test prosedürleri ve sonuç verisi
  4.6 Teknoloji eklerinden gelen yöntemler
5 Kapsam analizleri
  5.1 Gereksinim kapsam analizi
  5.2 Yapısal kapsam ölçütü ve ölçüm yöntemi
  5.3 Veri ve kontrol bağlaşımı analizi
  5.4 Kaynak koda izlenemeyen nesne kodu
  5.5 Kapsam boşluklarının çözümü
6 Doğrulama ortamı
  6.1 Test düzenekleri ve hedef donanım
  6.2 Hedef ile emülatör ve simülatör farkları
  6.3 Doğrulama araçları ve kalifikasyon
7 Geçiş kriterleri
  7.1 Doğrulama faaliyetlerine giriş
  7.2 Kredi amaçlı test koşusu
8 Bölümleme bütünlüğünün doğrulanması
9 Derleyici, bağlayıcı ve yükleyici varsayımları
10 Yeniden doğrulama
  10.1 Doğrulama eksenindeki etki analizi
  10.2 Regresyon seçimi
11 Önceden geliştirilmiş yazılım
12 Çok sürümlü benzemez yazılım
13 PDI doğrulaması
14 Doğrulama verisi
  14.1 Doğrulama durumları, prosedürleri ve sonuçları
  14.2 İz verisi
  14.3 Problem raporlamaya aktarım

Bölüm bölüm yazım rehberi

1. Amaç ve kapsam

Planın hangi yazılımı, hangi yazılım seviyesinde (software level) ve hangi konfigürasyonlarla kapsadığı burada yazılır; bileşenler farklı seviyedeyse her kuralın hangisine uygulandığı baştan belli olmalıdır. Ayrı bir test planı ya da kurum prosedürü varsa hangi konunun hangi belgede tanımlandığı da söylenir: her konu tek belgede tanımlanır, diğerleri ona atıf yapar.

Verilecek kararlar:

• Plan hangi yazılım bileşenlerini kapsıyor; seviyeleri farklıysa hangi bileşene hangi ölçüt uygulanıyor?
• Ayrı bir test planı ya da kurum prosedürü var mı; hangi konu SVP'de, hangisi orada?
• Sistem düzeyindeki testlerden ya da donanım doğrulamasından bir hedef için kredi alınacak mı?
• Plan hangi temel çizgi (baseline) için geçerli, hangi değişiklikte yeniden yayımlanır?

2. Doğrulama organizasyonu

Gözden geçiren, test geliştiren, testi koşan, kapsam analizini yapan ve sonuçları onaylayan kim? Kişi adı yerine rol yazılır; rol–kişi eşlemesi proje kaydında tutulur. Arayüzler dört yöne bakar: bulgular geliştirmeye döner; türetilmiş gereksinimler (derived requirement) ve emniyet etkili bulgular sistem süreçlerine bildirilir; temel çizgiler ve problem raporu (problem report) akışı konfigürasyon yönetiminden gelir; kalite güvencesi tanıklık eder ve denetler.

Verilecek kararlar:

• Hangi roller var; bir kişi hangi rolleri birlikte üstlenebilir, hangilerini üstlenemez?
• Doğrulama bulgusu geliştirmeye hangi kayıtla ve kimin üzerinden döner?
• Sistem süreçlerine geri bildirimi kim yapar, hangi kayıtla?
• Tedarikçinin doğrulama çıktısını kim gözden geçirir ve hangi ölçütle kabul eder?

3. Bağımsızlık

Bağımsızlık (independence) hedef bazındadır ve kişi düzeyindedir: bağımsızlık aranan bir hedefte doğrulamayı yapan, doğruladığı ürünü üretmemiş olmalıdır; ayrı bir bölüm ya da şirket gerekmez. SVP bu hedefleri tek tek listeler ve her biri için "kim olamaz" sorusunu yanıtlar. Aşağıdaki örnek tablonun değerleri Ek A tablolarından alınmıştır.

Hedef	Seviye A	Seviye B	Kim
A-3 #1, #2, #7: yüksek seviyeli gereksinimler	Bağımsız	Bağımsız	Gereksinimleri yazmamış biri
A-4 #1, #2, #7: düşük seviyeli gereksinimler	Bağımsız	Bağımsız	Bu gereksinimleri yazmamış biri
A-4 #8, #9, #13: mimari ve bölümleme	Bağımsız	Gerekmez	Mimariyi yazmamış biri
A-5 #1: kodun gereksinimlere uyumu	Bağımsız	Bağımsız	Kodu yazmamış biri
A-5 #2, #6: kodun mimariye uyumu, doğruluğu	Bağımsız	Gerekmez	Kodu yazmamış biri
A-5 #8, #9: parametre verisi öğesi (PDI) dosyası	Bağımsız	Bağımsız	#8 dosyayı üretmemiş, #9 #8'i yapmamış biri
A-6 #3: düşük seviyeli gereksinim testleri	Bağımsız	Bağımsız	Test durumlarını (test case) yazan, o kodu yazmamış olmalı
A-6 #4: düşük seviyeli gürbüzlük (robustness) testleri	Bağımsız	Gerekmez	Aynı kural
A-7 #1, #2: test prosedürleri ve sonuçları	Bağımsız	Gerekmez	#1 prosedürü yazmamış, #2 testi koşmamış biri
A-7 #3, #4: gereksinim kapsamı	Bağımsız	Gerekmez	Test durumlarını yazmamış biri
A-7 #5 … #8: yapısal kapsam ve bağlaşım	Bağımsız	#6 … #8 bağımsız	Analiz edilen testleri yazmamış biri ya da araç
A-7 #9: izlenemeyen nesne kodu	Bağımsız	Hedef yok	Ek kodu derleyici ürettiğinden elle yapılan doğrulama bağımsız sayılır

Seviye C ve D'de doğrulama hedeflerinde bağımsızlık aranmaz; kalite güvencesinin bağımsızlığı yazılım kalite güvencesi planının (Software Quality Assurance Plan, SQAP) konusudur (SQAP şablonu). Yüksek seviyeli gereksinimlere dayalı testlerde (A-6 #1, #2) hiçbir seviyede bağımsızlık aranmaz. Bağımsızlığı sağlayan araç 6. bölümde anılır. Ayrıntı: Yazılım Doğrulama: Bağımsızlık.

Verilecek kararlar:

• Ekip büyüklüğü her bağımsız hedefe ayrı bir kişi bulmaya yetiyor mu; yetmiyorsa çapraz doğrulama eşleri nasıl atanıyor?
• Hangi hedefte bağımsızlık bir araçla sağlanıyor ve o aracın çıktısı nasıl doğrulanıyor?
• Bağımsızlık hangi kayıtta, hangi alanla görünür?
• Yazar ile doğrulayanın aynı kişi olmasını araç mı engelliyor, yoksa kalite güvencesi örneklemeyle mi denetliyor?

Zayıf ifade	Güçlü ifade
"Gerekli yerlerde bağımsızlık sağlanacaktır."	"Bölüm 3.1'deki her hedefte gözden geçirme kaydının yazar ve gözden geçiren alanları zorunludur; <araç adı> aynı kişinin iki alana girilmesine izin vermez."

4. Doğrulama yöntemleri

Bu bölüm, seviyede geçerli her doğrulama hedefinin hangi yöntemle karşılanacağını söyler. Yöntem adları bu planda tanımlanır; gereksinimlerin doğrulama yöntemi özniteliği gereksinim standardında aynı üç değeri alır: Test, Analiz, Gözden geçirme. Gözden geçirmeler (4.1) için kontrol listelerinin (checklist) adı, sürümü ve standart kurallarına numarayla atfı; analizler (4.2) için izlenebilirlik (traceability), en kötü durum yürütme süresi (worst-case execution time, WCET), yığın, bellek haritası, bağlantı ve yükleme analizlerinin yöntemi yazılır; testle gösterilemeyen gereksinimlerin hangi analizle karşılandığı da buraya girer. Test tarafında (4.3–4.5) normal aralık ve gürbüzlük test durumlarının nasıl türetileceği, hangi gereksinimin hangi seviye ve ortamda sınanacağı, test prosedürlerinin (test procedure) biçimi ve sonuç kaydının alanları tanımlanır. Teknoloji ekleri kullanılıyorsa model simülasyonu, biçimsel analiz ve nesne yönelimli tasarımın ek hedefleri için yöntem 4.6'ya; model izlenebilirlik ve model kapsam analizi 4.2 ve 5'e yazılır (kitabın 14–16. bölümleri).

En okunur biçim hedef–yöntem–kayıt eşlemesidir; otoritenin "bu hedefi nasıl karşıladınız?" sorusunun cevabı tek satırda bulunur:

Hedef	Yöntem	Kayıt
A-3 #1	Gereksinim gözden geçirmesi, gereksinim kontrol listesi	Gözden geçirme kaydı
A-5 #6	Kod gözden geçirmesi; yığın ve WCET analizi	Gözden geçirme kaydı, analiz raporları
A-6 #5	Hedefte donanım/yazılım entegrasyon testi	Test sonuçları

Verilecek kararlar:

• Seviyede geçerli her A-3 … A-7 hedefi için birincil yöntem ne ve kanıt hangi kayıtta durur?
• Kontrol listeleri hangi standart kurallarına (GS-, TS-, KS-) numarayla atıf yapıyor, kim güncelliyor; bir aykırılıkta onaylı sapma kaydı nasıl aranıyor?
• Doğrulama yöntemi Analiz ya da Gözden geçirme olan gereksinimin gerekçesi ve kanıtı hangi kayıtta durur?
• Normal aralık test durumları hangi kuralla seçiliyor (eşdeğerlik sınıfı, sınır değer ve çözünürlüğü); gürbüzlük test durumları hangi anormal koşulları (geçersiz değer, bozuk veri, anormal başlatma, çerçeve süresi aşımı, izinsiz durum geçişi) kapsıyor?
• Hangi gereksinim hangi test seviyesinde sınanıyor; hangi testler yalıtılmış bileşen üzerinde, hangileri tümleşik hedefte koşuyor?
• Geçti/kaldı kararı otomatik mi; otomatikse karşılaştırmayı yapan betik araç envanterinde mi?

Zayıf ifade	Güçlü ifade
"Yazılım test edilecektir."	"Her yüksek seviyeli gereksinim için normal aralık test durumu; girdi aralığı, giriş verisi geçerliliği, başlatma ya da durum geçişi tanımlayan her gereksinim için ayrıca gürbüzlük test durumu yazılır; anormal koşul türleri 4.3'te listelidir. Donanım/yazılım entegrasyon testlerinin tamamı <hedef kart ve revizyonu> üzerinde koşar."
"Gerekli analizler yapılacaktır."	"WCET <araç adı ve sürümü> ile statik olarak hesaplanır, hedefte ölçümle karşılaştırılır; her görev için kalan pay sonuç raporunda verilir."

5. Kapsam analizleri

Gereksinim kapsam analizi iki adımlıdır: her gereksinimin karşısında test durumu var mı (eşleme) ve testler gereksinimin bütün koşullarını sınıyor mu (yeterlilik)? Yapısal kapsam analizinin (structural coverage analysis) ölçütü seviyeye bağlıdır: Seviye C'de satır kapsama (statement coverage), B'de buna ek olarak karar kapsama (decision coverage), A'da ayrıca değiştirilmiş koşul/karar kapsama (modified condition/decision coverage, MC/DC). Plan dört şeyi söylemelidir: seviyenin ölçütü, ölçümün aracı ve sürümü, ölçülen kod biçimi (kaynak ya da nesne kodu) ve donatılmış (instrumented) kodla toplanan verinin uçacak koda nasıl bağlandığı. Veri ve kontrol bağlaşımı (data and control coupling) analizi mimarideki arayüz listesine dayanır. Seviye A'da kaynak koda izlenemeyen nesne kodunun ele alınışı 5.4'tedir (seçenekler). Boşluklar dört sınıfa göre çözülür: test eksikliği, gereksinim eksikliği, gereksiz kod (extraneous code) ve devre dışı bırakılmış kod (deactivated code). Devre dışı kodun iki türünün ve savunmacı kodun nasıl ele alınacağı da buradadır (Kapsanmayan Kodlar).

Kapsam boşluğu koda bakılarak yazılan testle kapatılmaz

Test eksikliği sınıfında çözüm, gereksinimden türetilen yeni ya da genişletilmiş test durumudur. Koda bakıp gereksinime dayanmayan test yazmak ise yöntemi tersine çevirir: kapsam verisi yalnızca gereksinim tabanlı testlerden toplanır. SVP her boşlukta önce kök nedenin bulunacağını ve yapısal kapsam için kullanılan her testin bir gereksinime izleneceğini açıkça yazmalıdır.

Verilecek kararlar:

• Yapısal kapsam hangi araçla, hangi kod biçiminde ve hangi derlemeden ölçülüyor?
• Donatılmış koddan alınan kapsamın donatılmamış koddaki kredi koşusuna geçerliliği nasıl gösteriliyor?
• Çevirici dili (assembly language) modülleri ve başlatma kodu için ölçütün karşılığı ve ölçüm yolu ne?
• Seviye A'da izlenemeyen nesne kodu analizi temsilî örnekle mi, tüm kodla mı yapılıyor?
• Gerekçeli analizle kapatılan boşlukları kim gözden geçiriyor ve kim kabul ediyor?

Zayıf ifade	Güçlü ifade
"Yapısal kapsam ölçülecektir."	"MC/DC, <araç adı ve sürümü> ile kaynak kod düzeyinde, donatılmış derlemeden toplanır; kredi koşusu donatılmamış imajla yapılır ve iki koşunun geçti/kaldı sonuçlarının aynı olduğu gösterilir."
"Kapsanmayan kod gerekçelendirilecektir."	"Her boşluk dört sınıftan birine atanır; gerekçeli analizle kapatılan boşluk, analizi yazmamış biri tarafından gözden geçirilir ve kapsam raporunda satır satır listelenir."

6. Doğrulama ortamı

Test düzenekleri (6.1), hedef donanımın parça numarası ve revizyonuyla, uyaran üreten yazılım ve veri yolu benzeticisi gibi bileşenleriyle anılır; düzeneğin kendisinin nasıl doğrulandığı ve konfigürasyon kontrolüne alındığı da söylenir. Emülatör ya da simülatörden kredi alınacaksa (6.2) hedeften farkları, her farkın hata yakalama yeteneğine etkisi ve o farkı kapatan doğrulama faaliyeti bir tabloda listelenir. Araçlar (6.3) için rol, çıktısının ayrıca doğrulanıp doğrulanmadığı ve gerekiyorsa araç kalifikasyon seviyesi (tool qualification level, TQL) verilir; kapsam araçları ve sonuç karşılaştıran betikler tipik TQL-5 adayıdır (DO-330 ve Yazılım Aracı Kalifikasyonu). Sürümlerin asıl kaydı yazılım yaşam döngüsü ortam konfigürasyon indeksidir (Software Life Cycle Environment Configuration Index, SECI); SVP sürüm yazıyorsa SECI ile aynı olmalıdır.

Verilecek kararlar:

• Kaç test düzeneği var, her biri hangi donanım revizyonuyla kurulu ve nasıl doğrulanıyor?
• Hangi testlerden emülatör ya da simülatörde kredi alınıyor; farklar nasıl kapatılıyor?
• Hangi doğrulama araçlarının çıktısı ayrıca doğrulanmıyor ve bunların TQL'i ne?
• Araçların kullanılan seçenekleri ve bilinen sorunları nerede değerlendiriliyor?

Zayıf ifade	Güçlü ifade
"Testler uygun bir test ortamında yapılır."	"Donanım/yazılım entegrasyon testleri <kart parça numarası ve revizyonu> ile kurulan <düzenek adı> üzerinde, düşük seviyeli testler <simülatör adı ve sürümü> üzerinde koşar; iki ortamın farkları ve kapatıldıkları faaliyet Tablo 6-2'dedir."

7. Geçiş kriterleri

Her doğrulama faaliyetinin hangi koşulla başlayacağı, bir kayıtla denetlenebilir biçimde yazılır. En kritik geçiş kredi amaçlı (for-credit) test koşusudur. Geliştirme boyunca koşulan testler kuru koşudur (dry run) ve kanıt sayılmaz. Kredi koşusu için en az üç koşul yazılır: kod temel çizgide, test durumları ve prosedürleri gözden geçirilmiş, test ortamı kayıtlı. Kredi koşusunda başarısız olan test problem raporuna dönüşür; raporun yaşam döngüsü yazılım konfigürasyon yönetimi planında (Software Configuration Management Plan, SCMP) tanımlanır (SCMP şablonu), SVP ona atıf yapar (örnek kriterler).

Verilecek kararlar:

• Her doğrulama faaliyetinin (gözden geçirme, analiz, test geliştirme, kredi koşusu) giriş koşulu ne ve kim kontrol ediyor?
• Kuru koşu zorunlu mu; kuru koşu kayıtları nerede tutuluyor?
• Kredi koşusunda bir test başarısız olursa koşu sürüyor mu; ne zaman bütün set yeniden koşulur?
• Kalite güvencesi hangi koşulara tanıklık ediyor ve nasıl haberdar ediliyor?
• Artımlı çalışmada kriter yapı başına mı, bileşen başına mı uygulanıyor?

Zayıf ifade	Güçlü ifade
"Kod hazır olduğunda resmî testlere başlanır."	"Kredi amaçlı koşuya şu koşullarla girilir: yazılım sürümü temel çizgide; test durumları ve prosedürleri gözden geçirilmiş, bulguları kapalı; ortam SECI'deki tanımla aynı; kuru koşudaki başarısızlıklar problem raporuna bağlı; kalite güvencesi <n> iş günü önce bilgilendirilmiş."

8. Bölümleme bütünlüğünün doğrulanması

Yazılım bölümlemesi (software partitioning) kullanılıyorsa bölümlerin birbirini bellek ve zaman yönünden etkileyemediği analiz ve testle gösterilir; ikisi birbirinin yerini tutmaz. Plan, paylaşılan kaynak listesine dayanan bölümleme analizini, hedefte koşan ihlal testlerini ve bölümleme konfigürasyon tablolarının doğrulanmasını tanımlar. Bu hedef (A-4 #13) her seviyede aranır, Seviye A'da bağımsızlıkla; Seviye D'de de bölümlemeyle ilgili düşük seviyeli gereksinim ve kodun erişilebilir ve doğrulanmış olması gerekir (DO-248C, FAQ #84). Bölümleme yoksa başlık kalır, altına gerekçesiyle "uygulanmaz" yazılır (Yazılım Bölümlemesi).

Verilecek kararlar:

• Bölümleme iddiası hangi paylaşılan kaynakları kapsıyor ve analiz matrisinin sahibi kim?
• İhlal testleri hangi senaryoları içeriyor, hangi konfigürasyonla koşuyor?
• Konfigürasyon tabloları nasıl doğrulanıyor; tabloyu üreten araç kalifiye mi?
• Platform tedarikçisinin kanıtı kullanılıyorsa kullanım kısıtlarına uyulduğu nasıl gösteriliyor?

9. Derleyici, bağlayıcı ve yükleyici varsayımları

Derleyiciye duyulan güven, bu ürünün nesne kodunun doğrulanmasından gelir ve başka bir ürüne taşınmaz; derleyicinin kalifiye edilmemesinin gerekçesi de budur ve PSAC'taki araç kararıyla aynı olmalıdır. Bağlayıcı ve yükleyici için de varsayımlar ayrı ayrı yazılır. Plan neyin varsayıldığını ve varsayımın hangi faaliyetle sınandığını yazar: yazılım geliştirme planında (Software Development Plan, SDP) dondurulan sürüm ve seçenekler, eniyileme (optimization) düzeyinin yapısal kapsama etkisi, Seviye A'da 5.4'teki analiz, üreticinin bilinen hata listesi, bellek haritası analizi ve yükleme imajının bütünlük denetimi. Seçeneklerin kendisi SDP'de tanımlanır; SVP onlara atıf yapar.

Verilecek kararlar:

• SDP'de dondurulan seçenekler ve eniyileme düzeyi hangi varsayıma dayanıyor; biri değişirse hangi test ve analiz yenilenir?
• Derleyicinin bilinen hata listesi kim tarafından, ne sıklıkla değerlendiriliyor?
• Bağlayıcı ve yükleyicinin çıktısı (bellek haritası, imaj, CRC) hangi analizle doğrulanıyor?
• Çalışma zamanı kütüphanesi ve başlatma kodu hangi kanıtla doğrulanıyor?

Zayıf ifade	Güçlü ifade
"Derleyici olgun ve yaygın bir üründür; doğru kod ürettiği varsayılır."	"<derleyici adı ve sürümü>, SDP'de dondurulan seçeneklerle kullanılır. Ürettiği nesne kodu gereksinim tabanlı testlerle ve 5.4'teki analizle doğrulanır; üreticinin bilinen hata listesi her sürüm değişiminde gözden geçirilir, etkilenen yapılar kodlama standardında yasaklanır."

10. Yeniden doğrulama

Değişiklik etki analizinin (change impact analysis) süreci SCMP şablonunda tanımlanır; SVP onun doğrulama eksenini doldurur: etkilenen testler iz verisiyle nasıl seçilir, hangi analizler yenilenir, hangi testler her derlemede koşar? Derleyici sürümü ya da seçeneği değişirse önceki test ve kapsam sonuçlarının geçerliliği ayrıca değerlendirilir. Problem raporunun kapanışı da yeniden doğrulamadır: sorunu bulan test ve etkilenen testler yeniden koşar.

Verilecek kararlar:

• Etkilenen testler iz verisinden nasıl seçiliyor; seçimi kim gözden geçiriyor?
• Her değişiklikte koşan asgari bir regresyon (regression) seti var mı, içeriği ne?
• WCET, yığın ve kapsam analizleri hangi değişiklik türünde yenileniyor?
• Kapsam verisi farklı derleme sürümlerinden birleştirilebilir mi; hangi koşulla?

Zayıf ifade	Güçlü ifade
"Değişiklikten sonra gerekli testler tekrarlanır."	"Etkilenen gereksinimlerin testleri, iz verisiyle bulunan bağlı bileşenlerin entegrasyon testleri ve <asgari setin adı> her yeni derlemede koşar; derleyici seçeneği değişirse yapısal kapsam ve 5.4 analizi yenilenir."

11. Önceden geliştirilmiş yazılım

Önceden geliştirilmiş yazılımın (previously developed software, PDS) doğrulama verisi bu projenin seviyesini ve bağlamını karşılamıyorsa, eksik hedeflerin nasıl karşılanacağı burada yazılır. Önce boşluk analizi yapılır: hangi hedef mevcut kanıtla karşılanıyor, hangisi eksik? Bağlam farkları (işlemci, derleyici, birlikte çalıştığı yazılım) da boşluk sayılır ve ilgili testlerin yeni hedefte yeniden koşulmasını gerektirebilir. Kullanma niyeti ve strateji PSAC'ta, uygulanışı SVP'dedir (24. Yazılım Yeniden Kullanımı).

Verilecek kararlar:

• Hangi PDS bileşenleri var; mevcut doğrulama verileri hangi seviyeye ve bağlama ait?
• Boşluk analizinde eksik çıkan hedefler hangi faaliyetle kapatılacak?
• Bağlam değişikliği hangi testlerin yeniden koşulmasını gerektiriyor?
• Kullanılmayan PDS işlevleri devre dışı bırakılmış kod olarak mı ele alınıyor?

12. Çok sürümlü benzemez yazılım

Çok sürümlü benzemez yazılım (multiple-version dissimilar software) seyrek kullanılır; kullanılıyorsa doğrulamanın tek sürümlü yazılımdan nasıl ayrıldığı burada yazılır. Plan sürümler arası uyumluluğun normal ve anormal koşullarda nasıl gösterileceğini, her sürümde eşdeğer hata yakalamanın nasıl sağlanacağını ve ekiplerin sınırlı etkileşiminin nasıl kanıtlanacağını anlatır. Benzemezlik bir doğrulama hafifletmesinin gerekçesi yapılacaksa dayanağı ve otoriteyle varılan mutabakat anılır (Sistem Emniyet Değerlendirmesi Bağlamında Yazılım).

Verilecek kararlar:

• Benzemezlik hangi düzeyde sağlanıyor: ekip, dil, derleyici, işlemci?
• Sürümler arası uyumluluk ve eşdeğer hata yakalama hangi testlerle gösteriliyor?
• Doğrulamada hangi hafifletme isteniyor ve PSAC'ta nasıl anılıyor?

13. PDI doğrulaması

Parametre verisi öğesi (parameter data item, PDI) kullanılıyorsa önce temel karar yazılır: PDI dosyası çalıştırılabilir nesne kodundan ayrı mı, onunla birlikte mi doğrulanacak? Ayrı doğrulama, standardın aradığı dört koşulun tümü gösterilebiliyorsa mümkündür; kodun veri zarfının (data envelope) tamamında normal aralık ve gürbüzlük testleriyle doğrulanması bu koşulların başındadır. Her PDI dosyası için iki soru kalır: dosya doğru ve eksiksiz mi (A-5 #8) ve bütün öğeleri doğrulamada ele alınmış mı (A-5 #9)? Kodla uyumluluk ve yükleme kontrolü SCMP'nin konusudur (Konfigürasyon Verisi).

Verilecek kararlar:

• PDI ayrı mı doğrulanıyor; dört koşulun her biri hangi kanıtla gösteriliyor?
• Veri zarfı nerede tanımlı; zarfın uçlarını zorlayan test PDI dosyaları hangileri?
• Hangi öğede yalnızca öznitelik, hangisinde değerin kendisi doğrulanıyor?
• PDI dosyasını üreten aracın çıktısı bağımsız bir yolla mı doğrulanıyor, araç kalifiye mi?

14. Doğrulama verisi

Yazılım doğrulama durumları ve prosedürleri (Software Verification Cases and Procedures, SVCP) gözden geçirme ve analiz prosedürlerini, test durumlarını ve prosedürlerini; yazılım doğrulama sonuçları (Software Verification Results, SVR) her faaliyetin sonucunu ve hangi konfigürasyon sürümüne ait olduğunu içerir. SVCP Seviye A ve B'de CC1, C ve D'de CC2; SVR her seviyede CC2'dir. İz verisi (trace data) gereksinim, test durumu, prosedür ve sonuç arasında iki yönlü kurulur. Beklenen ile gerçekleşen arasındaki her fark problem raporuyla izlenir; bulgu ile problem raporu arasındaki sınırı SCMP çizer, SVP hangi doğrulama bulgusunun bu akışa ne zaman girdiğini söyler.

Verilecek kararlar:

• Doğrulama verisi hangi biçimde tutuluyor: belge mi, temel çizgiye alınmış araç veritabanı mı?
• Her sonuç kaydı hangi alanları zorunlu taşıyor (yazılım, prosedür ve ortam sürümü, koşan kişi, tarih)?
• İz verisinin iki yönlü ve eksiksiz olduğu nasıl denetleniyor?
• SCMP'deki bulgu–problem raporu sınırı doğrulamada nasıl uygulanıyor; kuru koşudaki başarısızlık ne zaman problem raporu açar?

Seviyeye göre farklar

SVP her seviyede beklenir; seviyeyle değişen, planın tarif etmesi gereken hedef sayısı ve bağımsızlıktır. Aşağıdaki sayılar Ek A'nın doğrulama tablolarından (A-3 … A-7) alınmıştır.

SVP'deki konu	Seviye A ve B	Seviye C	Seviye D
Doğrulama hedefi sayısı	A: 43; B: 41	34	9
Bağımsız karşılanan hedef	A: 25; B: 13	Yok	Yok
Yapısal kapsam ölçütü	A: MC/DC, karar, satır; B: karar, satır	Satır kapsama	Aranmaz
Veri ve kontrol bağlaşımı	Aranır	Aranır	Aranmaz
Düşük seviyeli gereksinim testleri ve kapsamı	Aranır	Aranır	Aranmaz
Gereksinim, mimari ve kod gözden geçirmeleri	Tümü	Hedef bilgisayarla uyum ve tasarım/kod doğrulanabilirliği düşer	Yalnız yüksek seviyeli gereksinimlerin üç hedefi ve bölümleme
İzlenemeyen nesne kodu	Yalnız Seviye A	Aranmaz	Aranmaz
Test prosedürü ve sonuç gözden geçirmesi	Aranır	Aranır	Aranmaz
PDI dosyası (A-5 #8, #9)	İkisi de, bağımsız	İkisi de	Yalnız #8

Seviye D'de testler yüksek seviyeli gereksinimlere dayanır; hedefte koşma ve bu gereksinimlerin test kapsamı yine aranır. A-1'den bu seviyede yalnız #1 ve #4 aranır; giriş kriterleri ve ortam tanımı hedef değildir, ama yazılırlarsa bağlayıcıdır.

DO-178C uyum tablosu

DO-178C	Konu	Şablondaki yer
§11.3.a	Organizasyon ve süreç arayüzleri	2 Doğrulama organizasyonu
§11.3.b	Bağımsızlığın sağlanma yöntemi	3 Bağımsızlık
§11.3.c.1	Gözden geçirme yöntemleri ve yardımcıları	4.1 Gözden geçirmeler ve kontrol listeleri
§11.3.c.2	İzlenebilirlik ve kapsam dahil analizler	4.2 Analizler; 5 Kapsam analizleri
§11.3.c.3	Test durumu seçimi, prosedür, veri	4.3 Test durumu seçimi; 4.4 Test seviyeleri ve ortam ataması; 4.5 Test prosedürleri ve sonuç verisi
§11.3.d	Test donanımı ve doğrulama araçları	6 Doğrulama ortamı
§11.3.e	Doğrulamaya giriş kriterleri	7 Geçiş kriterleri
§11.3.f	Bölümleme bütünlüğünün doğrulanması	8 Bölümleme bütünlüğünün doğrulanması
§11.3.g	Derleyici, bağlayıcı, yükleyici varsayımları	9 Derleyici, bağlayıcı ve yükleyici varsayımları
§11.3.h	Değişiklikte yeniden doğrulama yöntemi	10 Yeniden doğrulama
§11.3.i	Uyumsuz temel çizgili PDS	11 Önceden geliştirilmiş yazılım
§11.3.j	Benzemez sürümlerin doğrulanması	12 Çok sürümlü benzemez yazılım
§4.2.h	Devre dışı kodun doğrulanması	5.5 Kapsam boşluklarının çözümü
§4.2.j.3	PDI doğrulama süreci	13 PDI doğrulaması
§4.3.b	Geçiş kriterinin üç öğesi	7.1 Doğrulama faaliyetlerine giriş
§4.4.2.a	Eniyileme ve yapısal kapsam	9 Derleyici, bağlayıcı ve yükleyici varsayımları
§4.4.2.b	İzlenemeyen nesne kodunun saptanması	5.4 Kaynak koda izlenemeyen nesne kodu
§4.4.2.c	Derleyici değişikliğinde yeniden doğrulama	10 Yeniden doğrulama
§4.4.3.a	Emülatör ve simülatör kalifikasyonu	6.3 Doğrulama araçları ve kalifikasyon
§4.4.3.b	Hedef ile emülatör/simülatör farkları	6.2 Hedef ile emülatör ve simülatör farkları
§6.2.a	Uçacak koddan farklı test kodu	5.2 Yapısal kapsam ölçütü ve ölçüm yöntemi
§6.2.b	Testle doğrulanamayan gereksinimler	4.2 Analizler
§6.4.1.a	Hedefte koşacak seçilmiş testler	4.4 Test seviyeleri ve ortam ataması
§6.4.4.3	Kapsam boşluklarının çözümü	5.5 Kapsam boşluklarının çözümü
§6.5	Doğrulama iz verisi	14.2 İz verisi
§6.6	PDI'nin ayrı doğrulanma koşulları	13 PDI doğrulaması
§11.14	Sonuç kaydı ve farkların raporlanması	14.1 Doğrulama durumları, prosedürleri ve sonuçları; 14.3 Problem raporlamaya aktarım
§12.1.3.d	Derleyici değişince önceki sonuçlar	10 Yeniden doğrulama; 11 Önceden geliştirilmiş yazılım
§12.2.1	Doğrulama aracı kalifikasyon ihtiyacı	6.3 Doğrulama araçları ve kalifikasyon

Teknoloji ekleri

Ek	Madde	Şablona etkisi
DO-331	MB.11.3.c.2	4.2 ve 5: model izlenebilirlik analizi, model kapsam ölçütü ve model kapsam analizi eklenir
DO-331	MB.11.3.c.4	4.6: simülasyon durumlarının seçimi, prosedürleri ve verisi; simülasyonun hangi hedefe kredi vereceği
DO-331	MB.11.3.d	6: simülasyon ortamı, araçları ve hedeften farkları
DO-332	OO.11.3	Madde değişmez; OO.6.7 ve OO.6.8'in eklediği iki hedefin (yerel tip tutarlılığı, dinamik bellek) yöntemi 4.6'ya yazılır
DO-333	FM.11.3.c.4	4.6: biçimsel analiz durumlarının seçimi, prosedürleri ve verisi
DO-333	FM.11.3.d	6: biçimsel yöntemler ve analiz araçları
DO-333	FM.6.7.1	5.2: yalnız biçimsel doğrulanan bileşende yapısal kapsama eşdeğer faaliyetler; testli bileşende yapısal kapsam aynen uygulanır

Bu eşleme bir başvuru aracıdır; maddelerin tam anlamı için standarda bakılır, eşleme onun yerine geçmez.

Diğer belgelerle tutarlılık

Bu belgede	Örtüşmesi gereken belge	Nasıl denetlenir
Bağımsızlık rolleri (3)	SDP: ekip yapısı ve geliştirme rolleri	Bağımsız her hedefte yazar ve doğrulayıcı farklı kişilere mi düşüyor?
Doğrulama araçları ve TQL kararları (6.3)	PSAC: araç listesi; SECI	Araç adı, sürümü ve kalifikasyon kararı üç yerde aynı mı?
Derleyici varsayımları (9)	SDP: geliştirme ortamı, derleyici seçenekleri	Varsayımlar SDP'de dondurulan seçeneklere ve eniyileme düzeyine mi dayanıyor?
Kapsam yaklaşımı, devre dışı kod, ek yöntemler (5, 4.6)	PSAC: ek hususlar ve teknoloji ekleri	PSAC'ta kredi istenen her yöntemin SVP'de uygulanışı var mı?
Doğrulamaya giriş kriterleri (7)	SDP: kodlama çıkış kriterleri	SDP'nin çıkış koşulu SVP'nin giriş koşulunu karşılıyor mu?
Kredi koşusu ve tanıklık (7.2)	SQAP: denetim ve tanıklık planı	Tanıklık edilecek koşular ve bildirim yolu SQAP'ta da var mı?
Bulgu akışı ve doğrulama verisinin kategorisi (14)	SCMP: problem raporlama, kontrol kategorileri	Bulgu–problem raporu sınırı yalnız SCMP'de mi; SVCP ve SVR kategorileri aynı mı?
Kontrol listeleri, doğrulama yöntemi adları (4)	Gereksinim, tasarım ve kodlama standartları	Liste maddeleri GS-, TS-, KS- numaralarıyla atıf yapıyor mu; doğrulama yöntemi değerleri gereksinim standardındakiyle aynı mı?

Sık hatalar

Hata	Tipik nedeni	Önlem
Plan faaliyetleri sayıyor; hangi hedefin nasıl karşılandığı çıkmıyor	Plan ekibin iş listesinden yazılmış	Yöntemler bölümüne hedef–yöntem–kayıt eşlemesi koymak
Kapsamın hangi kod biçiminde, hangi derlemeden ölçüldüğü yazılmamış	Kapsam aracı plandan sonra seçilmiş	Aracı planlamada seçmek, ölçüm düzenini küçük bir denemeyle sınamak
Çevirici dili modülleri ve başlatma kodu kapsam planının dışında	Aracın desteklemediği kod unutulmuş	Ölçütün çevirici dilindeki karşılığını ve ölçüm yolunu yazmak
Simülatör farkları "önemsiz" diye geçilmiş	Fark analizi yapılmamış	Fark tablosu; her farkı kapatan faaliyeti adlandırmak
Geliştirme sırasında koşulan sonuçlar kanıt diye sunuluyor	Kuru koşu ile kredi koşusu ayrılmamış	Kredi koşusunun giriş koşullarını 7.2'ye yazmak
Derleyici varsayımı tek cümle: "derleyici güvenilirdir"	Varsayım ile gerekçe karıştırılmış	Varsayımı bir doğrulama faaliyetine bağlamak; bilinen hata listesini değerlendirmek
Regresyon "gerekli testler tekrarlanır" diye bırakılmış	Seçim yöntemi tanımlanmamış	İz verisine dayalı seçim kuralı ve asgari regresyon seti

Yayımlamadan önce

• Seviyede geçerli her A-3 … A-7 hedefi için bir yöntem ve kanıtın duracağı kayıt adıyla belirtilmiş mi?
• Bağımsızlık tablosu seviyenin bağımsız hedeflerinin tamamını içeriyor ve her satırda "kim olamaz" sorusu bir rolle yanıtlanmış mı?
• Yapısal kapsamın aracı, ölçüldüğü kod biçimi ve donatılmış kodla ilişkisi yazılı mı; Seviye A'da izlenemeyen nesne kodu yöntemi seçilmiş mi?
• Hangi testlerin hedef donanımda koşacağı ve hedef dışı ortamların farkları listelenmiş mi?
• Kredi amaçlı koşunun giriş koşulları bir kayıtla denetlenebilir mi?
• Derleyici seçenekleri, araç listesi ve sürümler SDP, PSAC ve SECI ile aynı mı?
• Uygulanmayan bölümler (bölümleme, PDS, benzemez yazılım, PDI) silinmek yerine gerekçesiyle "uygulanmaz" diye işaretlenmiş mi?
• Plana yazılan her faaliyet gerçekten yapılacak ve kaydı gösterilebilecek mi?

Otoritenin planlarda baktığı noktalar SW SOI-1, planın uygulanmasında baktıkları SW SOI-2, SW SOI-3 ve SW SOI-4 kontrol listelerindedir.

İlgili bölümler

• 5. Yazılım Planlama
• 9. Yazılım Doğrulama
• 10. Yazılım Konfigürasyon Yönetimi
• 13. DO-330 ve Yazılım Aracı Kalifikasyonu
• 14. DO-331 ve Model Tabanlı Geliştirme ve Doğrulama
• 15. DO-332 ve Nesne Yönelimli Teknoloji ve İlgili Teknikler
• 16. DO-333 ve Biçimsel Yöntemler
• 17. Kapsanmayan Kodlar: Ölü, Gereksiz ve Devre Dışı Bırakılmış Kodlar
• 21. Yazılım Bölümlemesi
• 22. Konfigürasyon Verisi
• 24. Yazılım Yeniden Kullanımı
• Ek A: Örnek Geçiş Kriterleri
• SW SOI-1, SW SOI-2, SW SOI-3, SW SOI-4
• Diğer şablonlar: PSAC, SDP, SCMP, SQAP, gereksinim standardı, tasarım standardı, kodlama standardı, genel bakış