Yazılım Konfigürasyon Tetkikleri

YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
Yazılım Konfigürasyon Tetkikleri
Software Configuration Audits
Zühre Yılmazer Seltürk
SST-Kalite Güvencesi Müdürlüğü
ASELSAN A.Ş., ANKARA
Seçil Gürsoy
REHİS-Kalite Güvencesi Müdürlüğü
ASELSAN A.Ş., ANKARA
[email protected]
[email protected]
• Konfigürasyon Durum
Status Accounting)
Özet
Konfigürasyon tetkikleri, ürün geliştirme süreci
sonunda ortaya çıkan Konfigürasyon Birimi’nin (KB),
kendisine atanan gerekleri tam olarak karşıladığının ve
kendisini tanımlayan dokümanlar ile uyumunun
gösterilmesi amacıyla yapılan, ürün konfigürasyon
doğrulamasına yönelik bir faaliyettir. Bildiride, bir
konfigürasyon yönetimi faaliyeti olan konfigürasyon
tetkikleri ile ilgili genel bilgi verilmiş ve ASELSAN
Savunma Sistem Teknolojileri (SST) ve Radar
Elektronik Harp ve İstihbarat Sistemleri (REHİS)
Grupları’ndaki konfigürasyon tetkikleri uygulaması,
yazılımlar açısından anlatılmış ve deneyimler
özetlenmiştir.
(Configuration
alt süreçleri ile tanımlanmaktadır.
Tasarım dokümantasyonu, KB’lerin tüm yaşam
döngüsü boyunca (geliştirme, teslimat, işletme, destek
vs.) bir sonraki yaşam döngüsü evresine geçilmesi ve
ürünün idamesi amacıyla temel alınacaktır. Bu nedenle
teknik şartnameleri temel alarak yürütülen tasarım
faaliyetleri,
tasarımı
tam
olarak
anlatan
dokümantasyon faaliyetleri ile birlikte yürütülmelidir
[1].
2. Yazılım Konfigürasyon Tetkikleri
2.1. Genel
Abstract
Configuration audit is a configuration verification
activity proving that a Configuration Item (CI) meets
the requirements stated in its performance specification
and conforms to the technical documentation that
defines it. In this paper, general information about the
configuration audit, which is a configuration
management activity, is given. Configuration audit
process in ASELSAN Defense Systems Technologies
(SST) and Radar Electronic Warfare Intelligence
Systems (REHIS) Divisions is described and
experiences gained are summarized.
1. Giriş
Konfigürasyon yönetimi faaliyetleri temel olarak
KB’lerin konfigürasyon temellerinin tanımlanması ve
kontrol altında tutulması amacıyla yürütülmektedir.
Konfigürasyon yönetimi faaliyetleri;
• Konfigürasyon
Identification)
Takibi
Tanımlama
(Configuration
• Konfigürasyon Kontrol (Configuration Control)
• Konfigürasyon Tetkikleri (Configuration Audit)
Konfigürasyon yönetimi faaliyetlerinin yazılım yaşam
döngüsü boyunca uygulanması gerekir.
Konfigürasyon tetkikleri yazılım iş ürünlerinin
(yazılım, doküman ve kayıtlar) ve geliştirme
faaliyetlerinin bağımsız değerlendirmesini içerir.
Tetkiklerin amacı, yazılım ürünlerinin gereksinimlere,
planlara, sözleşmeye uygunluğunu ve ürünlerin fiziksel
olarak tamlığını belirlemektir. Yazılımın müşteriye
(ürünün müşterisi; son kullanıcı, sistem mühendisi,
donanım mühendisi vb. olabilir) teslim edilmeden önce
tetkiklerinin tamamlanmış olması bu açıdan önemlidir.
Ayrıca firmalar, müşterisine konfigürasyon tetkik
kayıtlarını göstererek sunduğu ürün veya hizmetin
kalitesinin doğrulanmış olduğunu (ürünün veya
hizmetin planlara, süreçlere, sözleşmeye uygunluğunu)
beyan edebilir.
Ürün konfigürasyonuna yönelik tetkikler; tetkik amacı,
içeriği ve tetkik edilen ürün açısından işlevsel (İKT) ve
fiziksel konfigürasyon tetkikleri (FKT) olarak ayrılır.
İşlevsel ve fiziksel konfigürasyon tetkiklerinin
donanımlar için farklı ürünler üzerinde yapılması söz
konusudur. İşlevsel tetkik “mühendislik prototipi”;
fiziksel tetkik üretim sonunda ortaya çıkan “ilk ürün”
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
üzerinde yapılır. Prototip ürün üretilmediği durumlarda
işlevsel tetkik “ilk ürün” üzerinde yapılabilir.
Yazılımlar için böyle bir ayrım söz konusu değildir. İş
ürünlerinin tamamlanmış olması durumunda aynı
tetkik toplantısında her iki tetkik de gerçekleştirilebilir.
İlgili standartlarda tetkik sürecinin “tetkik öncesi”,
“tetkik” ve “tetkik sonrası” aşamaları ile bölümlendiği
görülmektedir. Tetkik öncesi aşamada tetkik tarihinin,
kaynakların,
tetkik
yönteminin,
katılımcıların
belirlenmesi; tetkik aşamasında tetkikin yapılması;
tetkik sonrası aşamada ise tetkikte tespit edilen eylem
maddelerinin tamamlanması öngörülmüştür.
Tetkik sürecini tanımlayan standartlarda müşteri
katılımı ve tetkike onay alınması vurgulanmıştır [2].
Teknik doküman paketi alımı gibi durumlarda tetkikin
bizzat müşteri tarafından gerçekleştirmesinden de
bahsedilmiştir [3].
2.2. Konfigürasyon Tetkikleri Uygulaması
ASELSAN SST ve REHİS Grupları’nda yazılım
geliştirme çalışmaları Sistem Tasarım Tanımı (STT)
dokümanının onaylanması ve yazılım birimleri
tarafından karşılanacak sistem seviyesi gereksinimlerin
belirlenmesi sonrasında başlar. (Bknz. Şekil 1) Yazılım
seviyesinde işlevsel temel, yazılım gereksinim
dokümanının onaylanması ile oluşur. İşlevsel ve
geliştirme temelini oluşturan dokümanlara ek olarak
test ve doğrulama raporları kullanılarak konfigürasyon
tetkikleri yapılır ve fiziksel konfigürasyon tetkiki
sonunda ürün temeli oluşur.
Konfigürasyon temellerinin tetkiklerle ilişkisi Şekil
1’den izlenebilir.
Konfigürasyon Tetkiki Kontrol Listesi ve Raporu ve
Yazılım Fiziksel Konfigürasyon Tetkiki Kontrol Listesi
ve Raporu kullanılarak yapılır [4-7]. Tetkiklere
sözleşmede belirtilmesi durumunda müşteri katılımı
sağlanır.
2.2.1. Tetkiklerin Yazılım Geliştirme Sürecindeki Yeri
Şekil 2: Konfigürasyon Tetkiklerinin Yazılım Geliştirme
Sürecindeki Yeri
Şekil 2’deki süreç izlenerek, test edilip doğruluğu
raporlanmış, süreçlere ve planlara uygun olarak
doküman seti hazırlanmış yazılım, konfigürasyon
tetkiki için hazırdır. Konfigürasyon tetkiklerinin
planlaması konfigürasyon tanımlama aşamasında
KB’lerin doküman planlaması ile birlikte yapılır.
Planlama, yazılımın müşteriye teslim edilmeden önce
tetkik edilmiş olması gerektiği göz önünde
bulundurularak yapılmalıdır.
İşlevsel tetkikinin yapılabilmesi için prototip ürünün
tasarımının tamamlanarak gereksinim dokümanı,
gereksinim, tasarım (yazılım birimleri), test tanımı
izlenebilirlik matrisleri ile tasarım doğrulama raporu
gibi tetkik girdilerinin hazırlanmış olması gerekir.
Fiziksel tetkikinin yapılabilmesi için geliştirme
sürecinde planlanan tüm dokümanların hazırlanmış ve
yazılımın çoğaltma için hazır durumda olması gerekir.
2.2.2. Sorumluluklar
Konfigürasyon tetkiki kapsamındaki sorumluluklar
aşağıda listelenmiştir: [5]
Tetkik Koordinatörü:
Konfigürasyon tetkiki yapılan yazılım ürünlerinin
geliştirilmesinde doğrudan sorumluluğu olmayan Proje
Yazılım Kalite Güvence Mühendisi bu görevi yürütür.
Tetkik koordinatörü;
Şekil 1: Konfigürasyon Yönetim Sürecinin Şekilsel Gösterimi
(Kısaltmalar için Şekil-2’ye bakınız)
Konfigürasyon tetkikleri Süreç Dokümanı ve
Yönergesi’ne uygun olarak; Yazılım İşlevsel
• Tetkiklerin planlanmasından
• Tetkik toplantılarının düzenlenmesinden
• Tetkik raporunun hazırlanmasından
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
• Düzeltici çalışmaların takibinden
• Tetkik
raporu
için
gereken
onayların
alınmasından,
raporun
duyurulması
ve
dokümantasyon
merkezine
aktarılmasından
(yayınlanmasından)
• Konfigürasyon tetkik sürecinin ölçümü için
gereken verilerin kaydedilmesi ve süreç sahibine
iletilmesinden sorumludur.
Tetkik Ekibi:
KB’nin özelliğine göre oluşturulan dinamik bir ekiptir.
İlgili Mühendislik Bölümleri temsilcileri, Proje Teknik
Yöneticisi, Proje Konfigürasyon Yönetim Sorumlusu,
Proje Kalite Yöneticisi ve Tetkik Koordinatöründen
oluşur. Sözleşmede belirtildiği takdirde müşteri
temsilcisi de ekipte yer alır. Gerek duyulduğunda alt
yüklenici temsilcileri de tetkik ekibinde yer alabilir.
REHİS / SST Kalite Güvencesi Bölüm Yöneticisi:
Tetkik raporlarını inceleyerek onaylamaktan (yazılım
geliştirme ve doğrulama faaliyetlerinin başarıyla
sonuçlandığını teyit etmekten) sorumludur.
Müşteri:
Sözleşmede belirtilmesi durumunda tetkiklere katılarak
tetkik raporunu inceler ve uygunluğunu belirler.
2.2.3. Yöntem
Tetkik Planı
Tetkik Planı
Prototip Ürün
Dokümanlar ve Kayıtlar
Tetkik Kontrol Listesi
Tetkik Planı
Prototip Ürün
Dokümanlar ve Kayıtlar
Tetkik Kontrol Listesi
1
İşlevsel
Konfigürasyon
Tetkiki Yap
• Tetkik Koordinatörü, Tetkik Kontrol Listesi’nin
tetkik öncesinde doldurulması gereken kısımlarını
doldurarak, tetkik toplantı duyurusu ve tetkikte
incelenecek dokümanlarla birlikte Tetkik Ekibi’ne
ve tetkike müşteri temsilcilerinin de katılımı
öngörülmüşse müşteri temsilcilerine iletir.
• Tetkik toplantısında tetkikin amacına uygun olarak
(işlevsel/fiziksel) tetkik soruları cevaplandırılır.
Tetkik sorularının kapsamı ile ilgili detaylı bilgi
2.2.4 ve 2.2.5 bölümlerinde verilmiştir. Düzeltme
gerektiren konular eylem maddeleri olarak tetkik
raporuna kaydedilir. Tetkik sırasında elde edilen
sonuçlar,
yapılması
gereken
çalışmalar,
sorumluları,
tamamlanma
tarihleri
ve
kaydedilmesinde yarar görülen bilgiler tetkik
raporunda yer alır. Eylem maddeleri Problem
Çözme
Süreci’ne
aktarılarak
takibi
ve
sonuçlanması sağlanır [8].
Tetkiki Sonuçlandır alt aşamasında;
• Tetkik Ekibi, düzeltme gereken konulardaki
çalışmalarını tetkik raporunda belirlenen süre
içinde tamamlar.
• Tetkik Koordinatörü düzeltme tarihleri gelen
problemlerin son durumunu yazılım hata takip
aracına işler.
Konfigürasyon Tetkik Süreci akışı Şekil 3’te
verilmiştir.
Konfigürasyon
Tetkiklerini Planla
İşlevsel/Fiziksel
Konfigürasyon
Tetkiki
Yap
aşamasında aşağıdaki adımlar takip edilerek tetkik
gerçekleştirilir.
• Tetkik Koordinatörü, tüm eylem maddeleri
kapandığında raporu onay için Kalite Güvencesi
Yöneticisi’ne sunar. Tetkik raporunu müşterinin de
onaylaması gerekiyorsa rapor müşteriye sunulur.
• Onaylı rapor yayınlanır, konfigürasyon kontrolü
altına alınır.
Fiziksel
Konfigürasyon
Tetkiki Yap
2
3
A2
A3
2.2.4. Yazılım İşlevsel Konfigürasyon Tetkiki
Tetkik
toplantısını
düzenle
21/31
Tetkiki
Gerçekleştir
22/32
Tetkiki
Sonuçlandır
Konfigürasyon
Tetkik Raporları
23/33
Şekil 3: Konfigürasyon Tetkik Süreci Akışı
Konfigürasyon Tetkiklerini Planla aşamasında
projede konfigürasyon tetkiki yapılacak yazılım
konfigürasyon birimleri (YKB) ve tetkik tarihleri
belirlenir.
Yazılım İşlevsel Konfigürasyon Tetkiki
Listesinde [6] tetkik amacına yönelik olarak:
Kontrol
Genel Sorular:
• Tetkikin planlanan tarihte yapıldığı
• Tetkike girdi iş ürünlerinin sürece uygun
hazırlanıp Gözden Geçirme Süreci’ne göre gözden
geçirildikleri
• Yazılım Gereksinim Özellikleri dokümanındaki
gereksinimlerin kaynaklandıkları dokümanlarla
izlenebilirliğinin tümüyle sağlandığı
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
• Mimari tasarımın ve ayrıntılı tasarımın proje
ekibince gözden geçirilip değerlendirildiği
• Yazılım Tasarım Tanımı dokümanında tanımlı
yazılım birimleri ile yazılım gereksinimleri
arasında izlenebilirliğin kurulduğu
• Kod gözden geçirme faaliyetlerinin gerçekleşip
kayıtlarının tutulduğu sorgulanır.
Testlerin Tanımlanmasına Yönelik Sorular:
• Yazılım Test Tanımı dokümanının yazılım
yeterlilik testlerinde doğrulanacağı belirtilen tüm
yazılım gereksinimlerine ilişkin doğrulama
yordamlarını kapsadığı,
• Sistem Entegrasyon Test Tanımı dokümanının
veya Sistem İşletme Test Tanımı dokümanının
sistem seviyesinde doğrulanacağı belirtilen yazılım
gereksinimlerine ilişkin doğrulama yordamlarını
kapsadığı,
• Yazılım gereksinim analizi aşamasında net
tanımlanmayıp, detayları tasarım aşamasına
bırakılmış
gereksinimlerin
doğrulama
yordamlarının, test tanımı dokümanlarında
kapsandığı sorgulanır.
Testlerin Gerçekleştirilmesine Yönelik Sorular:
• Yazılım beyaz kutu testlerinin yapılıp kayıtlarının
tutulduğu,
• Yazılım Test Raporu’nun oluşturulduğu,
• Sistem seviyesinde doğrulanacağı belirtilmiş tüm
yazılım gereksinimleri için sistem seviyesi testlerin
yapılmış ve raporlanmış olduğu,
• Yazılım testlerinde kullanılmış test yazılımları
varsa bu yazılımların doğrulanıp konfigürasyon
kontrolü altına alındığı,
• İşlevsel tetkik kapsamındaki
gereksinimlerinin doğrulandığı,
tüm
yazılım
• Başarısız testler için sorun/değişiklik kayıtlarının
oluşturulduğu,
• Test raporları dışında belirtilmiş uygunsuzluklar
varsa bunların kayıt altına alınmış olduğu,
• YKB’ye ait hata kayıtlarının tümünün doğrulanmış
ve değişikliklerin iş ürünlerine yansıtılmış olduğu
sorgulanır.
• Tetkikin planlanan tarihte yapıldığı,
• Yazılım için Yazılım Geliştirme Planında (YGP)
planlanan tüm iş ürünlerinin üretildiği,
• YGP’de planlanan iş ürünlerinin sürece uygun
hazırlanıp Gözden Geçirme Süreci’ne göre gözden
geçirildikleri,
• Üretilen tüm iş ürünlerinin güncel yazılım sürümü
ile uyumlu olduğu,
• Yazılımın yüklenmesi ve çalıştırılmasını tarifleyen
dokümanların hazırlanmış olduğu,
• Yazılım geliştirme ortamlarının, test yazılımlarının
ve müşteriye teslim edilmeyen yazılımların
konfigürasyon takibinin yapıldığı,
• Yazılımın sistemin diğer birimleri ile ilişkisinin
görülebilmesi için sistem ürün ağacında
gösterilmiş olduğu sorgulanır.
Tetkik sorularının hazırlanmasında ilgili standartların
gereklerinin karşılanmasına dikkat edilmiştir [1-2], [910].
Tetkik kontrol listelerinde yer alan her sorunun olumlu
cevaplanma kriteri tanımlıdır.
Tetkik sonrasında güncellenen iş ürünlerinin
yayınlanması ile “Ürün Temeli” oluşur. Ürün temelini
oluşturan iş ürünlerinin revizyon ve tarih bilgisi
Fiziksel Konfigürasyon Tetkik Raporu’nda belirtilir.
KB’ler için tetkiklerin tamamlanma durumu
Konfigürasyon Durum Takibi süreci tarafından takip
edilir.
2.2.6. Konfigürasyon Tetkiklerinin Başarı Kriterleri
Tetkik raporlarının “uygun” olarak işaretlenmesi için;
birime ait tüm gereksinimlerin karşılanmış olduğu,
gereksinimlerle ilgili tüm Problem Çözme Süreci
kayıtlarının kapatılmış olduğu, birimin dokümanlarıyla
uyumluluğu konularını sorgulayan tetkik sorularının
olumlu cevaplanmış olması gerekir. Bu sorulara
olumsuz cevap verilmişse tetkik raporu “uygun değil”
olarak sonuçlanır.
2.2.7. Yazılım Konfigürasyon Tetkiklerinin Tekrar
Edilmesi
Tetkikler aşağıda belirtilen durumlarda tekrarlanır:
2.2.5. Yazılım Fiziksel Konfigürasyon Tetkiki
Yazılım Fiziksel Konfigürasyon Tetkiki
Listesinde tetkik amacına yönelik olarak;
Kontrol
• İşlevsel
temelin
değişmesi;
yazılımın
değiştirilebilirliğini etkilemişse (eski ürünün yerine
güncel ürünün kullanılamaması durumunda) KB
için birden fazla tetkik yapılır.
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
• Tetkik raporu olumsuz sonuçlanmışsa yeni bir
yazılım
versiyonu
için
gerekli
testler
tekrarlandıktan, ürün ve dokümanlarında gerekli
düzeltmeler yapıldıktan sonra tetkik tekrarlanır.
İşlevsel ve fiziksel tetkikin yapıldığı yazılım versiyonu
aynı olmalıdır. Yazılım versiyonunun fiziksel tetkikten
önce değişmesi durumunda fiziksel tetkikten önce
işlevsel tetkik tekrarlanmalıdır.
2.2.8. Yazılım Konfigürasyon Tetkikleri ile İlgili
Metrikler
ASELSAN REHİS ve SST Grupları’nda Yazılım
konfigürasyon tetkikleri ile ilgili aşağıdaki metrikler
raporlanmaktadır:
• İKT/FKT Gerçekleşme Oranı: Projede İKT/FKT’si
gerçekleşen YKB Oranı
• İKT/FKT Başarı Oranı: Projede İKT/FKT’si
başarılı YKB Oranı
Tetkik süreci için aşağıdaki ölçüm/metrikler de
kullanılabilir:
• Konfigürasyon tetkikleri süreci için harcanan
işçilik (YKB başına)
• İKT/FKT tetkik eylem maddelerinin hedeflenen
tarihte kapanma oranı
• Konfigürasyon tetkiklerinin planlanan tarihe göre
sapma süresi
3. Tartışma
Konfigürasyon tetkikleri, yazılım geliştirme ve
doğrulama faaliyetlerinin başarı ile tamamlandığını
doğrulayan kritik bir kilometre taşıdır. Konfigürasyon
tetkikleri sürecinin etkinliği için, tetkik ve ürün
geliştirme süreçlerinin, iş ürünlerinin tanımlı olması
ve süreçlerin uygulanması için gerekli kaynakların
ayrılması gerekmektedir.
Projenin planlama aşamasında konfigürasyon tetkik
planlaması da yapılmalıdır.
Tetkik sorularının anlaşılır olması, yorum içermeyecek
şekilde cevaplanabilir olması, soruların olumlu
cevaplanma kriterlerinin tanımlı olması tetkik
sonuçlarının güvenilirliğine katkıda bulunacaktır.
Gereksinim yönetimi, tasarım, kodlama ve test
faaliyetlerinin uygulamasında şirket içinde kullanım
yöntemi tanımlanmış araçların kullanılması tetkik
aşamasında kayıtların
katkıda bulunmaktadır.
takibi
ve izlenebilirliğine
Edinilen bir başka tecrübe, ilk sürüm tetkiklerinin
sonrakilere kıyasla uzun sürdüğü ve çok sayıda eylem
maddesi tespit edildiği, aynı yazılımın sonraki
tetkiklerinde bunların giderek azaldığıdır. Başarısız
olsa da ilk tetkiki yapmak önemli uygunsuzlukların
giderilmesini sağlayarak yazılım için tetkik sürecinin
tamamlanmasını hızlandırmaktadır. Ancak tetkiklerin
çok erken yazılım versiyonları ile yapılması tekrar
tetkiklerinin artmasına neden olabilir. Tetkik edilecek
versiyona karar vermek amacıyla test raporlarının
başarı yüzdesi, hata kayıtlarının doğrulanma durumu
ve iş ürünlerinin olgunluğu incelenebilir.
Tetkik süreci ile ilgili olarak tetkiklerden önce tetkik
ekibine süreçle ilgili eğitim verilmesi, beklentilerin
aktarılmasında ve ürün geliştirme ekiplerinde süreçle
ilgili farkındalık yaratılmasına katkıda bulunmaktadır.
Tetkik soru listeleri yazılım yaşam döngüsü boyunca
üretilmesi gereken iş ürünlerini ve kayıtları da
sorgulamaktadır. Bu açıdan tetkikler tanımlı
geliştirme
sürecinin
uygulanmasına
katkı
sağlamaktadır. Geliştirme sürecinin yazılım kalite
güvence mühendisleri tarafından izlenerek geliştirme
boyunca iş ürünlerinin ve kayıtların takip edilmesi,
tetkik aşamasında tespit edilebilecek eksiklerin
azalmasını sağlayacaktır.
4. Sonuç
Bildiride (yazılım) konfigürasyon tetkikleri hakkında
bilgi verilmiş ve ASELSAN REHİS ve SST
Grupları’nda uygulanan tetkik süreci ve öneriler
anlatılmıştır.
Konfigürasyon tetkikleri, kuruluş içinde tanımlı
geliştirme
sürecinin
uygulanmasına
yönelik
sorgulamalarıyla yazılım ürün kalitesinin artmasına
katkı sağlar.
Yazılım yaşam döngüsünün önceki aşamalarında
uygulanan faaliyetlerle ilgili olarak tetkiklerde bulunan
bir uygunsuzluğun giderilmesi, daha maliyetli ve
zamanında gerçekleştirilmesinin faydalarını içermeyen
katma değeri düşük bir çalışma olabilmektedir. Bu
durumun önlenmesi için geliştirme süreçlerinde yer
alan gözden geçirme, test, değerlendirme toplantısı
gibi
faaliyetlerin
zamanında
gerçekleştirilerek
kayıtlarının oluşturulması, eksikliklerin ve hataların
yazılım tetkik aşamasına kadar gelmeden fark edilerek
giderilmesi,
uygunsuzluk
ve
tekrar
tetkik
maliyetlerinin azaltılmasına katkıda bulunacaktır.
YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları 2008 (9-10 ekim 2008, İstanbul)
5. Kaynaklar
[1] MIL-HDBK-61 Configuration Management Guidance 30
September 1997
[2] ACMP 5 NATO Requirements for Configuration Audits,
July 1998
[3] Design
Acquisition
Guidebook
https://akss.dau.mil/dag/GuideBook/
[4] MSSD-KY-07,
Konfigürasyon
Tetkikleri
Süreç
Dokümanı, Rev B, 01.05.2008
[5] MSSD-SG-20, Yazılım Geliştirme Süreci Yönergesi,
Rev. B, 01.05.2008
[6] MSFR-KY-01 Yazılım İşlevsel Konfigürasyon Tetkiki
Kontrol Listesi ve Raporu, Rev E, 01.05.2008
[7] MSFR-KY-02 Yazılım Fiziksel Konfigürasyon Tetkiki
Kontrol Listesi ve Raporu, Rev E, 01.05.2008
[8] AQAP-160 NATO Integrated Quality Requirements for
Software Throughout the Life Cycle, Edition 1,Temmuz
2001
[9] MIL-STD-973 Configuration Management 13 January
1995
[10] MIL-STD-1521 B Military Standard Technical Reviews
and Audits for Systems, Equipments and Computer
Software