Ana içeriğe geç

Planlar ve Standartlar Kontrol Listesi

Bu kontrol listesi (checklist), beş yazılım planının ve üç geliştirme standardının birlikte gözden geçirilmesi (review) içindir: belgeler ilk kez yayımlanıp temel çizgiye (baseline) alınmadan önce ve sonra her revizyonda. Gözden geçirmeyi belgelerin yazarları dışındaki proje mühendisleri, doğrulama ve konfigürasyon yönetimi sorumluları yapar; kalite güvencesi de katılır. Sorulan üç şeydir: plan seti yazılım seviyesinin gerektirdiği her şeyi karşılıyor mu, belgeler birbiriyle tutarlı mı ve yazılanlar bir kayda bakılarak denetlenebilir mi?

DO-178C'de bu iş planlama sürecinin gözden geçirilmesidir (§4.6). Sonucu, Tablo A-1'in iki hedefinin (objective) kanıtıdır: planların DO-178C ile uyumu (#6) ve planların eşgüdümlü geliştirilip revize edilmesi (#7). Planların neden ve nasıl gözden geçirildiği 5. Yazılım Planlama bölümünde, belge belge içerikleri Plan ve Standart Şablonları sayfalarında, listelerin ortak kullanımı genel bakış sayfasında anlatılır. Otoritenin planlama denetiminde baktığı noktalar SW SOI-1 listesindedir; bu liste ondan önce, ekibin kendi gözden geçirmesinde belgelerin içeriğine bakar. Kalite güvencesinin planlara ilişkin güvencesi (A-9 #1) ise Kalite güvencesi denetimi listesindedir.

Bir bakışta​

ÖzellikDeğer
DO-178C maddesi§4.6 planlama sürecinin gözden geçirilmesi; içerik ölçütü §4.2–§4.5 ve §11.1–§11.8
Ek A hedefleriA-1 #6: A, B ve C'de gerekli, D'de aranmaz. A-1 #7: A, B ve C'de gerekli, D'de aranmaz. İkisinde de bağımsızlık (independence) hiçbir seviyede aranmaz. Maddeler ayrıca A-1 #1–#5'in çıktısına bakar: #1 ve #4 A–D'de, #2, #3 ve #5 A–C'de gerekli
Gözden geçirilen veriBeş plan: yazılım sertifikasyon planı (Plan for Software Aspects of Certification, PSAC), yazılım geliştirme planı (Software Development Plan, SDP), yazılım doğrulama planı (Software Verification Plan, SVP), yazılım konfigürasyon yönetimi planı (Software Configuration Management Plan, SCMP) ve yazılım kalite güvencesi planı (Software Quality Assurance Plan, SQAP); gereksinim, tasarım ve kodlama standartları; Seviye D'de beş plan. Plan setinin atıf yaptığı kurum süreçleri ve ek planlar tutarlılık açısından
Başvuru verisiDO-178C Ek A (seviyeye göre hedefler) ve uygulanan teknoloji ekleri (supplement); yazılım seviyesini veren emniyet değerlendirmesi çıktıları; yazılıma tahsis edilen sistem gereksinimleri; araç envanteri ve yazılım yaşam döngüsü ortam konfigürasyon indeksi (Software Life Cycle Environment Configuration Index, SECI) taslağı; otoriteyle önceki görüşmelerin kayıtları
Kaydın gideceği yerGözden geçirme kaydı → yazılım doğrulama sonuçları (Software Verification Results, SVR), A-1 #6 ve #7'nin çıktısı. Bulgular (finding) → kayıt içinde. Belgeler temel çizgiye alındıktan sonra bulunan kusur → SCMP'deki sınıra göre problem raporu (problem report) ya da değişiklik talebi (change request)
İlgili şablonPlan ve Standart Şablonları: PSAC, SDP, SVP, SCMP, SQAP, gereksinim, tasarım ve kodlama standardı
Madde önekiPLS

Gözden geçirmeye giriş koşulları​

  • Gözden geçirilecek belgeler numarası ve sürümüyle listelenmiş ve konfigürasyon yönetimi altında; set, birlikte yayımlanacak sürümlerden oluşuyor.
  • Başvuru verisi tanımlı sürümleriyle gözden geçirenlerin erişiminde: yazılım seviyesini veren emniyet değerlendirmesi çıktıları, tahsis edilen sistem gereksinimleri ve araç envanteri.
  • Her belgenin uyum tablosu (DO-178C maddesi → belge bölümü) ve plan setinin tutarlılık matrisi belgelerle birlikte dağıtılmış.
  • Gözden geçirenler belli: her belgeye yazarı dışında en az bir kişi, setin tamamına tutarlılık için en az bir kişi atanmış; kalite güvencesinin katılımı kayda geçecek.
  • Bu kontrol listesinin projede kullanılan sürümü ve eklenen proje maddeleri kayda yazılacak.

Kontrol listesi​

Her madde evet/hayır sorusudur: "Evet" istenen durumdur, "Hayır" bir bulgudur ve kayda sınıfıyla yazılır; sondaki parantez maddenin geçerli olduğu seviyeleri ve dayanağını verir.

Plan setinin bütünlüğü​

  • PLS-01 Yazılım seviyesinin gerektirdiği belgelerin hepsi gözden geçirmeye girmiş mi? Örneğin Seviye A–C'de beş plan ve üç standart, Seviye D'de beş plan; birleştirilmiş bir belgede her birinin içeriği ayrı bölümlerde bulunabiliyor. (A–D · §4.2.a)
  • PLS-02 Yazılım seviyesi (bileşenler arasında fark varsa her bileşenin seviyesi) bütün belgelerde aynı geçiyor ve PSAC'ın dayandığı emniyet değerlendirmesi sürümü, sistemin güncel temel çizgisindeki sürüm mü? (A–D · §4.1.a)
  • PLS-03 Plan seti kurum süreçlerine, ek planlara (test planı, gereksinim yönetim planı gibi) ya da tedarikçi planlarına atıf yapıyorsa bu belgeler sürümleriyle anılmış ve bu projede neyin farklı uygulandığı yazılmış mı? (A–C · §4.6.d)

DO-178C'ye uyum​

  • PLS-04 Seviyede geçerli her Ek A hedefi için plan setinde bir faaliyet, onu yapacak rol ve kanıtın duracağı kayıt gösterilebiliyor mu? Örneğin hedeften plan bölümüne giden eşleme satır satır izlenebiliyor ve boş satır kalmıyor. (A–D · A-1 #1)
  • PLS-05 Her belgenin uyum tablosu, §11.1–§11.8'de o belgeye düşen harfli maddelerin hepsini, maddeyi gerçekten karşılayan bir bölümle eşliyor mu? Örneğin "uygulanmaz" denen her madde için bir gerekçe yazılı. (A–C · A-1 #6)
  • PLS-06 SVP'deki bağımsızlık listesi, Ek A'da bu seviyede bağımsızlık isteyen doğrulama hedeflerinin hepsini içeriyor ve her biri için organizasyonda bu bağımsızlığı sağlayacak bir rol gösteriliyor mu? (A–B · §11.3.b)
  • PLS-07 SQAP'ta tanımlanan kalite güvencesi rolü, organizasyon şemasında denetleyeceği işi yöneten kişiye bağlı olmayan ve düzeltici faaliyeti (corrective action) zorunlu kılma yetkisi olan birine karşılık geliyor mu? (A–D · §11.5.b)

Planlar arası tutarlılık​

  • PLS-08 Tutarlılık matrisindeki her konu tek belgede tanımlanmış, öteki belgeler o konuda yalnızca atıf yapıyor ya da tanımla çelişmeyen bir özet veriyor mu? Örneğin PSAC'taki doğrulama özeti SVP'de olmayan bir faaliyet vaat etmiyor. (A–C · A-1 #7)
  • PLS-09 Her araç, derleyici ve kütüphane bütün belgelerde aynı adla, aynı sürümle ve aynı rolle geçiyor; sürüm anan her yer SECI'deki değeri veriyor mu? (A–C · §4.1.g)
  • PLS-10 Roller (yazar, gözden geçiren, kalite güvencesi, konfigürasyon yöneticisi, değişiklik kontrol kurulu) bütün planlarda aynı adla ve aynı sorumlulukla geçiyor mu? (A–C · A-1 #7)
  • PLS-11 SDP ve SVP'deki geçiş kriterlerinde anılan her temel çizgi SCMP'nin temel çizgi listesinde aynı adla bulunuyor ve SQAP'ın denetim takviminde bir denetim noktasına karşılık geliyor mu? Örneğin kriterin istediği gözden geçirme kaydı da SCMP'de kontrol kategorisi belirlenmiş bir kayıt türü. (A–C · A-1 #7)
  • PLS-12 SVP'deki test hatası akışı ve SQAP'taki uygunsuzluk (nonconformance) akışı, SCMP'de tanımlı problem raporlama akışına atıf yapıp onun durum adlarını ve kapanışı onaylayan rollerini mi kullanıyor? Örneğin SQAP ikinci bir durum akışı tanımlamıyor, yalnızca kalite güvencesine özgü sınıfları ve hedef süreleri ekliyor. (A–C · §4.1.g)

Ölçülebilirlik​

  • PLS-13 Her geçiş kriteri (transition criteria) için, sağlandığını gösterecek kaydın adı planda yazılı mı? Örneğin "gereksinimler olgunlaşınca" yerine "gereksinim gözden geçirme kaydı kapanmış ve gereksinimler temel çizgide" deniyor. (A–C · §4.3.b)
  • PLS-14 Planlar gözden geçirme, analiz ve test kayıtlarının hangi alanları taşıyacağını tanımlıyor mu? Örneğin her kayıt bakılan verinin kimliğini ve sürümünü, faaliyeti yapan kişiyi ve verinin yazarını (bağımsızlık kayıttan görülebilsin diye), kullanılan yöntemi (kontrol listesi ve sürümü dahil) ve ortamın sürümünü gösterecek. (A–C · §4.6.c)
  • PLS-15 SDP'deki yaşam döngüsü modeli, PSAC'taki takvimde ve proje planında görünen artım ve teslim yapısıyla örtüşüyor mu? Örneğin artımlı çalışılacaksa geçiş kriterleri artım bazında yazılmış, takvimde karşılığı olmayan katı bir şelale tarif edilmemiş. (A–C · §4.1.b)
  • PLS-16 Planlardaki taahhütler, kimin neye bakarak karar vereceğini söylemeyen "gerektiğinde", "uygun görülen durumlarda" gibi ifadelerden arınmış mı? Örneğin SQAP'taki her denetimin sıklığı bir olayla ya da süreyle, örneklem büyüklüğü bir sayıyla verilmiş. (A–C · §4.6.b)

Ek hususlar ve teknoloji ekleri​

  • PLS-17 PSAC'ın ek hususlar (additional considerations) listesi, araç envanteri, mimari ve yeniden kullanılan bileşenlerle karşılaştırıldığında eksiksiz mi; her husus için ya bir yaklaşım ya da gerekçeli bir "uygulanmaz" yazılmış mı? (A–D · §4.1.d)
  • PLS-18 PSAC'ta anılan her ek husus SVP'de bir doğrulama yaklaşımıyla, SCMP'de bir kontrolle karşılanıyor mu? Örneğin devre dışı bırakılmış kodun (deactivated code) mekanizmasının nasıl doğrulanacağı ya da parametre verisi öğesinin (parameter data item, PDI) nasıl yüklenip uyumluluğunun nasıl denetleneceği yazılı. (A–D · §4.2.k)
  • PLS-19 Uygulanan teknoloji ekleri (DO-331, DO-332, DO-333) PSAC'ta adıyla ve gerekçesiyle anılmış, eklerin istediği ek içerik (ör. DO-331'de model standardı) plan setinde bir yerde bulunuyor mu? (A–C · §11.1.c)
  • PLS-20 Tedarikçi kullanılıyorsa iş bölümü, uyulacak tedarikçi planlarının sürümü ve gözetim yaklaşımı PSAC, SQAP ve SCMP'de aynı biçimde anlatılıyor mu? (A–D · §4.2.l)

Standartların denetlenebilirliği​

  • PLS-21 Her standarttan seçilen birkaç kural örnek bir iş ürününe uygulandığında, iki gözden geçiren aynı "uyuyor / uymuyor" kararına varıyor mu? Örneğin "fonksiyonlar mümkün olduğunca kısa tutulur" gibi ölçütsüz bir kural yok. (A–C · §4.5)
  • PLS-22 Standartlar, SVP'deki yöntemlerle doğrulanamayacak yapıları yasaklıyor ya da kullanım koşuluna bağlıyor mu? Örneğin yapısal kapsamı (structural coverage) ölçülemeyen ya da zaman analizine girmeyen bir yapı (dinamik bellek, özyineleme, sınırsız iç içe kesme) koşulsuz serbest bırakılmamış. (A–C · §4.5.c)
  • PLS-23 Gürbüzlük (robustness) standartlarda karşılık buluyor mu? Örneğin gereksinim standardı geçersiz girdi ve arıza davranışının nasıl yazılacağını, kodlama standardı savunmacı programlama kurallarını tanımlıyor. (A–C · §4.5.d)
  • PLS-24 Standartlardan sapma (deviation) süreci tek yerde tanımlı mı; onay yetkisi, kayıt biçimi ve kalite güvencesinin sapma kayıtlarını nasıl denetleyeceği belli mi? (A–C · iyi uygulama)

Ortam ve araçlar​

  • PLS-25 Plan setinde ve SECI taslağında adı geçen her araç (derleme ve test betikleri dahil) araç envanterinde bulunuyor ve araç kalifikasyonu (tool qualification) gerekmediği söylenen her aracın çıktısını doğrulayan faaliyet SVP'de gösteriliyor mu? Örneğin test sonuçlarını toplayan betiğin çıktısını kimin, neye bakarak denetleyeceği yazılı. (A–D · A-1 #4)
  • PLS-26 Derleyici, bağlayıcı (linker) ve kod üreteci (code generator) için kullanılacak seçenekler, eniyileme (optimization) düzeyi dahil, planda yazılı ve bu seçeneklerin yapısal kapsam analizine ve nesne kodu doğrulamasına etkisi SVP'de ele alınmış mı? (A–C · §4.4.1.e)
  • PLS-27 Derleyici, bağlayıcı ya da yükleyici (loader) sürümü veya seçenekleri proje ortasında değişirse hangi testlerin yeniden koşulacağına ve kapsamın yeniden ölçülüp ölçülmeyeceğine nasıl karar verileceği SVP'de yazılı mı? Örneğin eski ve yeni derlemenin nesne kodu karşılaştırılıyor, fark çıkan bileşenlerin testleri ve kapsam analizi yenileniyor. (A–C · §4.4.2.c)
  • PLS-28 Hedef dışı bir test ortamından (emülatör, simülatör) kredi alınacaksa SVP bu ortamla hedef bilgisayar arasındaki farkları tek tek listeliyor ve her fark için hedefte koşulacak testi ya da yapılacak analizi gösteriyor mu? Örneğin kesme gecikmesini, bellek eşlemeli donanım arayüzlerini ve zamanlama davranışını sınayan testler hedefte koşulacak diye işaretlenmiş. (A–C · §4.4.3.b)

Plan değişikliği ve revizyonu​

  • PLS-29 Planlar kendi revizyon yolunu tanımlıyor mu: değişikliği kim başlatır, etkilenen öteki belgeler nasıl bulunur ve hangi değişiklikte otoriteye yeniden gidilir? (A–D · §4.2.e)
  • PLS-30 Bu gözden geçirme bir revizyon içinse, değişikliğin etkilediği öteki planlar ve standartlar bulunmuş ve aynı kapsamda güncellenmiş ya da etkilenmedikleri gerekçelendirilmiş mi? (A–C · §4.1.g)

Araçla denetlenebilecek maddeler​

Plan gözden geçirmesi çoğunlukla okuma işidir; yine de birkaç madde bir sorgu ya da küçük bir betikle hızlanır.

MaddeAraç türüGözden geçirene kalan
PLS-04, PLS-05Hedef–bölüm eşlemesini tutan gereksinim ya da belge yönetim aracında boş eşleme sorgusuEşlenen bölümün hedefi gerçekten karşılayıp karşılamadığı; eşleme dolu, içerik boş olabilir
PLS-08Belge numarası ve bölüm atıflarının hedef belgede var olduğunu denetleyen çapraz atıf betiğiAtıf yapılan bölümün, atıf yapanın söylediğini gerçekten söyleyip söylemediği
PLS-09, PLS-25Belgelerdeki araç adı ve sürüm dizgelerini SECI taslağıyla ve araç envanteriyle karşılaştıran betikFarkın bilinçli mi (ör. doğrulama ortamında başka sürüm) yoksa hata mı olduğu; kalifikasyon gerekmez denen aracın çıktısını doğrulayan faaliyetin o çıktıyı gerçekten kapsadığı
PLS-11Temel çizgi ve kayıt türü adlarını belgelerden çıkarıp karşılaştıran betikAynı adın aynı içeriği ve aynı zamanı anlatıp anlatmadığı
PLS-16Belirsiz ifade listesiyle metin taramasıBulunan ifadenin bağlamında gerçekten belirsiz olup olmadığı; listede olmayan ama ölçülemeyen taahhütler

Bir madde araç raporuna bakılarak işaretleniyor ve rapor ayrıca doğrulanmıyorsa araç bir doğrulama faaliyetinin yerini almış olur; kalifikasyon gerekip gerekmediği 13. DO-330 ve Yazılım Aracı Kalifikasyonu bölümündeki ölçütlerle değerlendirilir.

Sık bulgular​

BulguTipik nedeniİlgili madde
PSAC'taki doğrulama özeti SVP'de olmayan bir faaliyeti vaat ediyor (ör. "bütün testler hedef donanımda koşulur")PSAC'ın erken yazılıp SVP olgunlaşınca güncellenmemesiPLS-08
Aynı derleyici SDP'de ve SVP'de farklı sürümle anılıyorPlanların farklı zamanlarda yazılması; sürümün esas kaydı olarak SECI'nin kullanılmamasıPLS-09
Seviye A projesinde yalnızca A'da bağımsızlık isteyen hedefler (ör. A-4 #8, A-5 #2) SVP'nin bağımsızlık listesinde yokListenin Seviye B projesinden kopyalanmasıPLS-06
Geçiş kriteri bir temel çizgiye atıf yapıyor, SCMP'de o adla temel çizgi yokSDP ve SCMP'nin birbirinden habersiz yazılmasıPLS-11
PSAC'ta kod üreteci kullanılmadığı yazıyor, SDP'nin araç tablosunda bir kod üretim aracı varAraç envanterinin tek yerde tutulmamasıPLS-17, PLS-25
Devre dışı bırakılmış kod PSAC'ta anılmış, SVP'de doğrulama yaklaşımı yokEk hususların yalnızca PSAC yazılırken düşünülmesiPLS-18
Karmaşıklık sınırı tasarım ve kodlama standardında farklı sayıyla geçiyorAynı kuralın iki belgede ayrı ayrı tanımlanmasıPLS-08
Kapsamın ölçüldüğü derleme ile uçuş derlemesinin seçenekleri farklı, fark değerlendirilmemişKapsam aracının donatma (instrumentation) için ayrı derleme istemesiPLS-26

İyi yazılmış bulgu​

Zayıf bulguİyi yazılmış bulgu
"Planlar tutarsız.""PLS-09: SDP'nin geliştirme ortamı bölümü derleyiciyi 5.2 sürümüyle, SVP'nin doğrulama ortamı bölümü aynı derleyiciyi 5.1 sürümüyle anıyor; SECI taslağında 5.2 kayıtlı. SVP SECI'ye göre düzeltilmeli ya da farkın gerekçesi yazılmalı."
"Geçiş kriterleri zayıf.""PLS-13: SDP'deki tasarıma geçiş kriteri ('gereksinimler yeterince olgunlaştığında') bir kayda bağlı değil. Kriter, ilgili gereksinimlerin gözden geçirme kaydının kapanmasına ve gereksinimlerin temel çizgiye alınmasına bağlanmalı."
"Standart belirsiz.""PLS-21: Tasarım standardındaki fonksiyon uzunluğu kuralı 'mümkün olduğunca kısa' diyor; iki gözden geçiren aynı örnekte farklı karar verdi. Kural sayısal bir üst sınırla ya da kodlama standardındaki sınıra atıfla yazılmalı."

Seviyeye göre uyarlama​

A-1 #6 ve #7 hiçbir seviyede bağımsızlık istemez; plan yazarları birbirinin belgesini gözden geçirebilir. Her belgeye yazarı dışında bir gözden geçiren atamak yine de iyi uygulamadır. Kalite güvencesinin plan ve standartlara ilişkin güvencesi (A-9 #1) ise A, B ve C'de bağımsızlıkla aranır ve kendi listesinde denetlenir.

SeviyeAranan A-1 hedefleriBu listeden uygulanan
A#1–#730 maddenin hepsi; PLS-06'daki liste 25 doğrulama hedefini kapsar
B#1–#730 maddenin hepsi; PLS-06'daki liste 13 doğrulama hedefini kapsar
C#1–#729 madde; doğrulama hedeflerinde bağımsızlık aranmadığı için PLS-06 düşer
D#1 ve #4A–D etiketli 9 madde (PLS-01, 02, 04, 07, 17, 18, 20, 25, 29)

Seviye D'de gözden geçirmenin kendisi bir hedef değildir ve üç standart beklenmez; beş plan ise yine yazılır ve planların faaliyetleri tanımlaması (A-1 #1) ile ek hususları ele alması (#4) aranır. Liste bu yüzden D'de de kullanılabilir: A–D etiketli maddeler bu iki hedefin karşılandığını gösterir, PLS-07 de D'de bağımsızlıkla aranan iki kalite güvencesi hedefinin (A-9 #2, #5) planda dayanağını sorar. A–C etiketli maddelerde "Hayır", D'de uyum bulgusu değil öneri olarak kaydedilebilir. Proje D'de de kısa bir kural seti yazmışsa standart maddeleri (PLS-21–PLS-24) ona uygulanır. Hangi hedefin hangi seviyede arandığı DO-178C Hedef Gezgini ile süzülebilir.

İlgili bölümler​