Monday, March 19, 2007

TAŞ TAŞ ÜSTÜNE


Resim 1

TAŞ TAŞ ÜSTÜNE

“… ve daha sonra acımasız bir kasaplık başladı. Kıyımda iddialı olanlar Makedonyalılar değil, gururlu yedi kapılı şehirden bir çok neslinin hataları ve hakaretlerinin intikamını alan Thebes’in eski düşmanları Phocia’lılar, Plataea’lılar ve diğer Boeotia halklarıydılar. İskender kıyımı durduruncaya kadar altı bin hayat kayboldu. Sonraki gün, isyankar şehrin kaderini belirlemek için Corinth konfedere’lerini topladı. Hakimler Thebes’e Thebes’in bir zamanlar Atina’ya ölçüp biçtiği cezayı biçti. Ceza ŞEHRİN YERLE BİR EDİLMESİ ve …” (Yunanistan’ın Tarihi J. B. BURY et all, s. 449)

Ünlü yazarımız Halikarnas Balikçısının yazılarında sık sık kaynak gösterdiği J.B. BURY, ‘A History of Greece to the Death of Alexandre Great’ adlı kitabinda sik sik eski Yunan, Makedonyalı ve Persli kavimlerin yakıp yıktığı, erkekleri katledilip kadınları muzaffer askerlere dağıtılan ve yerle bir edilen, TAŞ TAŞ ÜSTÜNE BIRAKILMAYAN mahlup şehirleri anlatır... Bu kitap yalnız Anadolu kültürünün güzelliklerini değil, onun her yönünü anlatır. Örneğin gökten üstümüze kuş pislemesinin uğur sayılması ile ilgili İskender’in bir hikayesi bile vardır bu kitapta… J.B. Bury’nin Heredot tarihi gibi çok sayıda elle tutulur tarih ve belgeye dayanan bu değerli kitabı günümüzde bile yaşayan antik Anadolu kültürünü daha iyi anlamamıza güçlü bir yardımcıdır.

Yakın zamanlarda kaybettiğimiz değerli arkeologumuz Ekrem AKURGAL ‘Türkiye’nin Eski Uygarlıkları ve Harabeleri’ adlı kitabının 222. sayfasında Didim’deki tapınağın 6. yy’da, arkaik dönemde yüzyıllık bir süre için çok ünlendiğini yazar. Bu dönemde Branşid ismi verilen bir rahip ailesi tarafından yönetilmişti bu tapınak. Branşid’ler o dönemde sağduyuyu temsil eden kahinlerdi. Nice kral onlara hediyeler gönderip onlardan fikir alıyordu o dönemde.

Didim Kahin Tapınağının ilk inşaatı Milattan önce 8. yüzyılda yapılmıştı(s. 223). Daha sonra MÖ 6. ve 5. yüzyıllarda yeniden inşa edilmiş, 112 sütunluk devasa bir mimari harika olmuştu. Fakat Ion ayaklanmasından sonra Persler Lade savaşını kazanınca Didim ve Mileti yakıp yıktılar. Branşid’leri yasakladılar ve ihanetlerine kıssa olarak İran’da Baktria’ya sürdüler. MÖ 4. yy’ın sonuna doğru İskender bölgeyi kurtarınca yeniden Kahin tapınağını inşa ettirdi. Devasa bir bina tasarladılar. “Bu kadar BÜYÜK BİR BİNA’nın kısa bir zamanda bitirilmesi mümkün değildi. İnşaat MÖ. 3. ve 2. yüzyıllarda devam etti ve bir bölümü ancak Roma döneminde bitirilebildi. Anlaşıldığı kadarı ile güney-batı ve kuzey bölümleri hiçbir zaman bitirilemedi…” (Akurgal, Ancient Civilization and Ruins of Turkey, s. 227).

İsa’dan önce 3. yüzyılda devasa bir bina inşaatına başlıyorsunuz. Bina daha önce, bilgiişlem jargonuyla, çok sayıda sürümleri çıkartılmış, 500 yıllık bir geçmişe, yıkıp yeniden yapma tarihine sahip… Bina defalarca yeniden yapılmış, mimari tasarımı zamanın içinde bir imbikten süzülmüş, damıtılmış. Sonra büyük bir yıkım, Pers yıkımı… Ve İskender’in dahiyane kararı… İskender, yine bilgiişlem jargonu ile, bir BÜYÜK SİSTEM yapmaya karar vermiş… Yapımı belki hiçbir zaman bitmeyecek, nesiller boyu devam edecek büyük bir boy ölçüşme… Günümüzdeki uzay istasyonu ve benzeri uzay çalışmaları gibi…



Resim 2
Didim Branşid Kahin Tapınağı, MÖ. 8 – MS 2. yy

Yaklaşık 1000 yıl süren bir inşa süreci ve tümü bitirilemeden büyük bir depremde yıkılan Didim Branşid’lerinin Kahin Tapınağı… ‘Taş taş üstüne bırakmamak’ ile mücadele eden, gerçekleştirmeye çalıştığı BÜYÜK SİSTEM’in yanında ömrü bile yetersiz kalan insanların, devlet adamlarının, askerlerin, sanatçıların ve taş ustalarının kararlılığı: bir nesilden diğerine emanet edilen bir kararlılık; taş taş üstüne koyma kararlılığı, BAŞKASININ KOYDUĞU TAŞIN ÜSTÜNE BİR TAŞTA BEN KOYAYIM kararlılığı ve alçak gönüllülüğü, hizmet anlayışı.

ABD Savunma Bakanlığı (DoD-Department of Defence)’in STSC – Software Technology Support Center’ının yani Yazılım Destek Merkezi’nin çıkarttığı, internettede kolaylıkla bulunabilen tartışma - CROSSTALK adlı dergide yayınlanmış bir makalenin başlığı “Niye Büyük Yazılım Projeleri Başarısız Oluyor – 12 Anahtar Soru”… SEI – Software Engineering Institute’tan Watts S. HUMPREY tarafından yazılmış bu makale yazılım projesi yönetiminde yapılan ilerlemelere karşın niye yazılım projelerinin rahatsız edici bir şekilde başarısız olduğunu sorguluyor. Bu makale “BÜYÜK-BOYUTLU YAZILIM PROJELERİ’nde kurumunuzun başarısızlıklarına neden olan unsurları inceliyor ve …”

BÜYÜK-BOYUTLU yazılım projeleri… LARGE SYSTEMS… BÜYÜK SİSTEMLER… Hızlı tren projesi… Büyük tüneller… Yeni yapılan hava trafik kontrolü sistemimizin SMART ihalesi…Marmara Ray… Metro projeleri… Yeni elektrik santralları… Nükleer santral… Elektrik dağıtım şebekeleri… Petrol nakil hatları… Uçak yapımı… Helikopter yapımı… Yolcu gemisi, yük gemisi yapımı… Savaş gemisi yapımı… Bunlar Türkiyemizin önündeki başarmamız gereken boy ölçüşmeler… Ve çoğunun içinde kontrol ve kumanda amaçlı büyük yazılım sistemleri var… Bunların üretimi ve bakımı için yurt dışına büyük döviz ödemeleri yapıyoruz.

Bunun bir çok nedeni olabilir. Ama bunların önemli bir tanesi BÜYÜK SİSTEMLER yapmanın basit ve kısa bir süreç sonucu değil, mesleğinin ustası kişilerin, usta çırak ilişkisi içinde, birkaç nesil ve ömür boyu çalışarak oluşturdukları sistemlerin 15- 20 yıl ısrarla kullanılarak geliştirilmesine dayanan bir kültür işi olmasıdır. Sorun TAŞ TAŞ ÜSTÜNE KOYMA kültürünü ve devlet politikasını ve siyasi iradesini oluşturmaktır.

Türkiye’mizin olağanüstü büyük ve zorlu coğrafyası, 100 milyona yaklaşacak nüfusu Türkiye Cumhuriyeti devletini ve bizleri politikadan, sanata, devlet idaresinden teknolojiye, sanayiye kadar BÜYÜK SİSTEMLER kullanmak, geliştirmek ve icad etmek zorunda bırakıyor. Geçmişte bu coğrafyayı kendi renkleri ile boyamayı başarmaya cüret edebilen milletimiz çağımızda Anadolu coğrafyasının önümüze koyup dayattığı her türlü büyük sistemle baş edebilme, her türlü büyük sistemin içinde kendi kişiliği ile var olabilme mücadelesi, boy ölçüşmesi ile karşı karşıya…

Harward Business Review’un Tem – Ağu 1993’te Building A Learning Organization – Öğrenen Bir Kuruluş İnşa Etmek makalesinde :

“Öğrenen bir kuruluş yeni bilgi ve sağduyuyu yaratmada, edinmede ve nakletmede ve kendi davranışını bunu yansıtacak şekilde değiştirmede usta olan kurumdur” der.

Harward Üniversitesinin bu dergisi toplumumuzun her kademesinde faydalı olabilecek, esinlenilebilecek bir kaynak… Ne yazık ki bu dergiyle tanışmamı sağlayan BİMSA’nın sağduyulu kütüphanesi artık bugünkü I-BİMSA içinde bulunmuyor… Öğrenen bir Kurum oluşturmak çok iddialı bir sav… Belki yalnız Microsoft vb. yabancı kuruluşlar için geçerli olabilecek bir şey…

Bilginin kurum içinde birikmesini sağlamak, en azından hedeflenebilecek bir şey… Ülkemizde bir çok kurum ISO9000 belgesi almış durumda, hak ederk ya da etmeyere… Dikkat edilirse ISO9000’in özü, oluşturmak istediği sistemin nüvesi, kurum bilgi ve tecrübesinin sistem içinde, kurum içinde biriktirilebilmesi ve kolayca nakledilebilmesidir…

Bir mühendisin karakteri bilgiye karşı aldığı tavırdan anlaşılır. Bilgiyi hak etmiyene vermemek, bilgiyi yetkin olmayan kişiye vermemek, karşılığını almadan ya da kıymetini bilmeyene bilgiyi vermemek, hakettiği saygıyı göstermeyene bilgiyi vermemek, bilgiyi idareli kullanmak, eldeki bilgileri yenileri gelmeden dağıtmamak, bilgiyi sağladığı güce uygun ve orantılı güçle kullanmak, bilgiyi bilmeyeni ezmek için kullanmak, bilgiyi iş yapmaktan çok biriktirmek amacıyla edinmek, bilgiyi o anki işi hallettiği kadar edinmek, bilgiyi çok basite indirgemek günlük işleri bitirmek için en etkin araç kılmak gibi… Ya da başkasından öğrendiği üzerine kendisinden önce gelenin üslubunu koruyarak küçük bir ekleme yapıp yapanın kimliğini belirlemesi için sistemin öngördüğü ve kendisine ait usta işaretini bir köşeye yerleştiren ve yaptığını çokta önemsemeyen bir usta mühendis gibi… Aslında ne kadar mühendis varsa dünyada ona yakın sayıda bilgiye karşı tavır söz konusudur… Üstelik bu sayı zaman içinde de değişir.

Yazıma antik dönemdeki BÜYÜK SİSTEMLER ile başlamıştım. 20 – 30 metre yüksekliğinde
112 taş sütun küçük bir şey değil bugün için bile… Ama bir şeyin büyüklüğünü belirleyen yalnız büyüklüğünün mutlak değeri değil onun nasıl algılandığıdır… Soyutlama seviyeleri çok 250 bin satırlık bir yazılım bir LARGE SYSTEMS olabilir. Nitekim, ADA ile yazılmış 250 bin satır C++ ile yazılmış 250 bin satırlık bir sistemden daha büyük olabilir… Ya da 5 kişilik bir ekibin yazdığı 800 bin satırlık bir paket 10 kişinin yazdığı 800 bin satırlık bir paketten daha büyük algılanabilir. Önemli olan yazılım paketinin büyüklüğü değil işin yapılması sırasında karşılaşılan güçlüklerden başarı ile çıkılmasıdır. Benzer bir yapı içinde 5 kişi, 10 kişinin karşılaştığı güçlükleri daha yoğun olarak yaşayabilir bazen…

Yazılım projelerinde boy ölçüşülen önemli bir güçlük ISO9000’de yüklenici tarafından yapılması gerektiği vurgulanan, müşteri tarafından belirtilen şartname maddelerinin doğal parçası olan, ‘implied requirements’’ın, yani yapılacak işin tümünün her yönüyle proje başlangıcında görülememesidir. Tıp alanından bir örnek verirsek, ameliyat masasına yatırdığınız canlının ne olduğunu tam olarak bilemiyorsunuz, ve bir amipin hücre duvarını tamir edeyim derken amip bir orangutana dönüşüyor masanın üzerinde, siz ameliyat yaparken…

Uzay istasyonu ya da Didim Branşid Kahini Tapınağı gibi bitmesi hiç mümkün olmayacak BÜYÜK SİSTEM’ler üzerinde çalışmak belki de daha küçük ve sınırlı sistemlerde karşılaştığımız güçlükleri yenmek için gerekli eşsiz tecrübeyi bize kazandırabilir… Nitekim, büyük yazılım sistemlerinde çalışan her usta mühendisin elinin altında bulunan, “Yazılım Ölçümlerinin Geçerliliğinin Değerlendirilmesi için Yöntem” IEEE 1992 adlı makaleyi yazan, Shneidewind, aslında, “Uzay Mekiğinin gelecek yazılım hatasının ne zaman olacağını haber veren ve IBM-Houston tarafından kullanılan” Schneidewind “Yazılım Güvenilirlik Modeli”’nin yaratıcısı belki de zamanımızın modern bir Branşid kahinidir…


Ali Rıza SARAL


Monday, March 05, 2007

YAZILIM YAŞAM DÖNGÜSÜ BELGELEME SİSTEMİ

Not: Bu derleme-çeviri-yazımı ileride olası bir nükleer santralın kontrol odasının Türkçeleştirlmesi çalışmasına küçük bir deneysel katkı olması amacı ile yaptım.
Konuyla ilgili kişilerin eleştiri ve tavsiyelerine şiddetle ihtiyacım(ız) var. Bu yazının ne anlattığını kolaylıkla anlayabildiniz mi? Lütfen arsaral(at)yahoo.com adresine yadırgadığınız beğendiğiniz şeyleri ve önerilerinizi yazınız. Saygılar. Ali Riza SARAL

YAZILIM YAŞAM DÖNGÜSÜ BELGELEME SİSTEMİ

(ISO9000, CMM, DO178B, Mil498, ISO12207, IEEE1407 uyumlu)

Derleyen : Ali R+ SARAL

İÇİNDEKİLER
-----------------
- KULLANICI KOŞULLARI BELGESİ - USER REQUIREMENTS DOCUMENT(URD)
- YAZILIM KOŞULLARI BELGESİ - SOFTWARE REQUIREMENTS DOCUMENT(SRD)
- MİMARİ TASARIM BELGESİ - ARCHITECTURAL DESIGN DOCUMENT(ADD)
- AYRINTILI TASARIM BELGESİ - DETAILED DESIGN DOCUMENT(DDD)
- PROJE GEÇMİŞİ BELGESİ - PROJECT HISTORY DOCUMENT(PHD)
- YAZILIM KURULUM DAĞILIMI YÖNETİMİ PLANI - SOFTWARE CONFIGURATION MANAGEMENT PLAN(SCMP)
- YAZILIM PROJESİ YÖNETİM PLANI - SOFTWARE PROJECT MANAGEMENT PLAN(SPMP)
- YAZILIM KALİTE GÜVENCESİ PLANI - SOFTWARE QUALITY ASSURANCE PLAN(SQAP)
- YAZILIM DOĞRULAYIŞ VE SINAYIŞ PLANI - SOFTWARE VALIDATION AND VERIFICATION PLAN(SVVP)
- KABUL SINAVI TANIMI - ACCEPTANCE TEST SPECIFICATION(AT)
- YAZILIM KULLANICI EL-KİTABI - SOFTWARE USER MANUAL(SUM)
- YAZILIM DEVİR BELGELERİ - SOFTWARE TRANSFER DOCUMENT(STD)

--------------------------------------------------------------------------------------------------

KULLANICI KOŞULLARI BELGESİ - USER REQUIREMENTS DOCUMENT(URD)

1. Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar, deyimler
1.4 Referanslar
1.5 Özet

2. Genel Açıklama
2.1 Ürüne genel bakış
2.2 Kullanıcı özellikleri
2.3 Genel Sınırlamalar
2.4 Kabuller ve bağımlılıklar
2.5 İşletimsel Ortam

3. Belirli Koşullar
3.1 Yetenek Şartları
3.2 Sınırlayıcı Şartlar

***********************************************************************************

YAZILIM KOŞULLARI BELGESİ - SOFTWARE REQUIREMENTS DOCUMENT(SRD)

1. Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar, deyimler
1.4 Referanslar
1.5 Özet

2 Genel Tarif
2.1 Güncel projelerler ilişkisi
2.2 Önceki ve sonraki projelerle ilişkisi
2.3 İşlev ve amaç
2.4 Ortamsal değerlendirmeler
2.5 Diğer sistemlerle ilişkisi
2.6 Genel kısıtlamalar
2.7 Model tarifi

3 Belirli Koşullar
3.1 İşlevsel koşullar
3.2 İcra seviyesi koşulları
3.3 Arayüz koşulları
3.4 İşletimsel koşullar
3.5 Kaynak koşulları
3.6 Doğrulama koşulları
3.7 Kabul testi koşulları
3.8 Belgeleme koşulları
3.9 Güvenlik koşulları
3.10 Taşınabilirlik koşulları
3.11 Kalite koşulları
3.12 Güvenilirlik koşulları
3.13 Bakım yapılabilirlik koşulları
3.14 Güvenlik koşulları
***********************************************************************************

MİMARİ TASARIM BELGESİ - ARCHITECTURAL DESIGN DOCUMENT(ADD)

1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar ve deyimler
1.4 Referanslar
1.5 Kısaözet

2 Ayrıştırış Tarifi
2.1 Modül ayrıştırışı
2.1.1 Modül 1 tarifi
2.1.2 Modül 2 tarifi
2.2 Eşzamanlı Süreç tarifi
2.2.1 Süreç1 tarifi
2.2.2 Süreç2 tarifi
2.3 Veri ayrıştırışı
2.3.1 Veri varlık 1 tarifi
2.3.2 Veri varlık 2 tarifi

3 Bağıntı Tarifi
3.1 Modül ler arası bağıntılar
3.2 Süreçler arası bağıntılar
3.3 Veri bağıntıları

4 Arayüz Tarifi
4.1 Modül arayüzü
4.1.1 Modül 1 tarifi
4.1.2 Modül 2 tarifi
4.2 İşlem Süreci arayüzü
2.2.1 Süreç 1 tarifi
2.2.2 Süre 2 tarifi

***********************************************************************************

AYRINTILI TASARIM BELGESİ - DETAILED DESIGN DOCUMENT(DDD)

1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar ve deyimler
1.4 Referanslar
1.5 Kısaözet

2 Ayrıştırış Tarifi
2.1 Modül ayrıştırışı
2.1.1 Modül 1 tarifi
2.1.1.1 Modül 1 ayrıntı
2.1.2 Modül 2 tarifi
2.1.1.2 Modül 2 ayrıntı
2.2 Concurrent process tarifi
2.2.1 İşlem Süreci 1 tarifi
2.2.1.1 Süreç 1 ayrıntı l
2.2.2 İşlem Süreci 2 tarifi
2.2.1.2 Süreç 2 ayrıntı
2.3 Data decomposition
2.3.1 Veri varlığı-entity 1 tarifi
2.3.1.1 Veri varlığı 1 ayrıntı
2.3.2 Veri varlığı 2 tarifi
2.3.1.2 Veri varlığı 2 ayrıntı

3 Bağıntı Tarifi
3.1 Modüller arası bağıntılar
3.1.1 Modüller arası bağıntılar ayrıntı
3.2 İşlem süreçleri arası bağıntılar
3.2.1 2 İşlem süreçleri ayrıntı
3.3 Veri bağıntıları
3.3.1 Veri bağıntıları ayrıntı

4 Arayüz Tarifi
4.1 Modül arayüzü
4.1.1 Modül 1 tarifi
4.1.1.1 Modül 1 ayrıntı
4.1.2 Modül 2 tarifi
4.1.2.1 Modül 2 ayrıntı
4.2 İşlem süreci arayüzü
2.2.1 Süreç 1 tarifi
2.2.1.1 Süreç 1 ayrıntı
2.2.2 Süreç 2 tarifi
2.2.2.1 Süreç 2 ayrıntı


***********************************************************************************


PROJE GEÇMİŞİ BELGESİ - PROJECT HISTORY DOCUMENT(PHD)

1. Proje Tanımı

2. Proje Yönetimi
2.1 Sözleşme yaklaşımı
2.2 Proje tanımı
2.3 Kullanılan Yöntemler
2.4 Planlama

3. Yazılım Üretimi
3.1 Kestirilen ve üretilmiş gerçek toplam program kod satır sayısı
3.2 Belgeleme
3.3 Kestirilen ve gerçek çaba
3.4 Bilgisayar kaynakları
3.5 Üretkenlik faktörlerinin analizi

4. Kalite Güvencesi Gözdengeçirimi

5. Finansal Gözdengeçirim

6. Sonuçlar

7. Sistemin İşletim ve Bakım Aşamasında İcra Seviyesi
***********************************************************************************

YAZILIM KURULUM DAĞILIMI YÖNETİMİ PLANI - SOFTWARE CONFIGURATION MANAGEMENT PLAN(SCMP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******

1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Sözlük
1.4 Referanslar

2 Yönetim

3 Kurulum Dağılım Tanımları

4 Kurulum Dağılım Kontrolü
4.1 Program Kod controlü
4.2 Medya kontrolü
4.3 Değişiklik kontrolü

5 Kurulum Dağılım Durum Takibi

6 Yazılım Kurlum Dağılımı Yönetimi için Araçlar, Teknikler ve Yöntemler

7 Sağlayıcı Kontrolü

8 Kayıt Biriktirme ve Korunması
***********************************************************************************

YAZILIM PROJESİ YÖNETİM PLANI - SOFTWARE PROJECT MANAGEMENT PLAN(SPMP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******

1 Giriş
1.1 Proje kısaözeti
1.2 Proje çıktıları
1.3 SPMP’nin gelişimi
1.4 Değinilen materyaller
1.5 Tanımlar ve kısaltmalar

2 Proje Düzenlenişi
2.1 Süreç modeli
2.2 Kurluşsal yapı
2.3 Kuruluşsal sınırlar ve arayüzler
2.4 Proje sorumlulukları

3 Yönetimsel Süreç
3.1 Yönetim hedefleri ve öncelikleri
3.2 Kabuller, bağıntılar ve kısıtlar
3.3 Risk yönetimi
3.4 İzleyiş ve kontrol mekanizmaları
3.5 Eleman buluş planı

4 Teknik Süreç
4.1 Yöntemler, araçlar ve teknikler
4.2 Yazılım Belgeleyiş sistemi
4.3 Project destek işlevleri

5 İş paketleri, Zaman Cetveli ve Bütçe
5.1 İş paketleri
5.2 Bağıntılar
5.3 Kaynak koşulları
5.4 Bütçe ve kaynak ayırışı
5.5 Zaman cetveli
***********************************************************************************

YAZILIM KALİTE GÜVENCESİ PLANI - SOFTWARE QUALITY ASSURANCE PLAN(SQAP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******

1 Amaç

2 Değinilen Belgeler

3 Yönetim

4 Belgeleyiş Sistemi

5 Standartlar, uygulamalar, yaklaşımlar ve ölçümler-metrics
5.1 Belgeleyiş Sistemi standartları
5.2 Tasarım standartları
5.3 Program yazış standartları
5.4 Yorum notları standartları
5.5 Sınayış standartları ve uygulayışları
5.6 Seçilmiş yazılım kalite güvencesi ölçümleri
5.7 Uyumun nasıl izleneceğinin ifadesi

6 Gözden geçirişler ve sözlü dinleyişler
6.1 Amaç
6.2 Koşulların aen alt sınırı

7 Sınav

8 Sorun raporlayış ve düzeltici eylem

9 Araçlar, teknikler ve yöntemler

10 Program metni kontrolü

11 Veri ortam kontrolü

12 Sağlayıcı kontrolü

13 Kayıt toplayış, bakım ve saklanışı

14 Eğitim

15 Risk yönetimi

16 Projenin geri kalan kısmının kısa özeti
***********************************************************************************

YAZILIM DOĞRULAYIŞ VE SINAYIŞ PLANI - SOFTWARE VALIDATION AND VERIFICATION PLAN(SVVP)
Yazılım Koşulları Aşaması
*******
Mimai Tasarım Aşaması
********
Ayrıntılı Tasarım Aşaması
********
Devir Aşaması
*******

1Amaç

2 Dayanılan Belgeler

3 Tanımlar

4 Sınama kısa özeti
4.1 Örgütleniş
4.2 Ana program
4.3 Kaynaklar özeti
4.4 Sorumluluklar
4.5 Araçlar, teknikler ve yöntemler

5 Sınama İdari İşlemleri
5.1 Gariplik raporlayış ve çözüş
5.2 Görev tekrar politikası
5.3 Sapma politikası
5.4 Kontrol işlemleri
5.5 Standartlar, uygulamalar ve yaklaşımlar

6 Sınama faaliyetleri

7 Yazılım Sınama Raporlayışı
7.1 İz sürülebilirlik matris kalıbı
7.2 Biçimsel ispatlar
7.3 Gözden geçirişler

***********************************************************************************

KABUL SINAVI TANIMI - ACCEPTANCE TEST SPECIFICATION(AT)
SVVP/AT
*******
Sistem Sınav Belirleyicisi
********************
Tümleşik Sınav Belirleyicisi
***********************
Birimsel Sınav Belirleyicisi
***********************

1 Sınav Planı
1.1 Giriş
1.2 Sınav unsurları
1.3 Sınanıcak özellikler
1.4 Sınanmayacak özellikler
1.5 Yaklaşım
1.6 Unsur geçiş/kalış koşulu
1.7 Askıya alış koşulu ve devam ediş koşulları
1.8 Sınav çıktıları
1.9 Sınayış görevleri
1.10 Ortamsal ihtiyaçlar
1.11 Sorumluluklar
1.12 Eleman durumu ve eğitim ihtiyaçları
1.13 Zamanlayış
1.14 Riskler ve umulmadık durumlar
1.15 Onaylar

2 Sınav Tasarımları (her test tasarımı başına...)
2.n.1 Sınav tasarım belirleyicisi
2.n.2 Test edilecek özellikler
2.n.3 Yaklaşım şartları
2.n.4 Sınanacak durumları belirlenişi
2.n.5 Özellik geçiş/kalış koşulu

3 Sınanıcak Durum Tarifleri(her test durumu başına...)
3.n.1 Sınanıcak durum belirleyicisi
3.n.2 Sınav unsurları
3.n.3 Giriş belirleyicileri
3.n.4 Çıkış belirleyicileri
3.n.5 Ortamsal ihtiyaçlar
3.n.6 Özel süreç koşulları
3.n.7 Durumlar arası bağımlılıklar

4 Sınav süreci(her sınav durumu başına...)
4.n.1 Sınav rapor belirleyicisi
4.n.2 Amaç
4.n.3 Özel şartlar
4.n.4 İşlem süreci adımları

5 Sınav RaporlarıTest Reports(her sınav süreci uygulaması başına bir tane...)
5.n.1 Sınav rapor belirleyicisi
5.n.2 Tarif
5.n.3 Faaliyet ve olay girişleri
***********************************************************************************

YAZILIM KULLANICI EL-KİTABI - SOFTWARE USER MANUAL(SUM)

1 Giriş
1.1 Niyetlenilen okuyucu kitlesi
1.2 Uygulanabilirlik ifadesi
1.3 Amaç
1.4 Bu belgeyi nasıl kullanmalı
1.5 İlgili belgeler
1.6 Yaklaşımlar
1.7 Sorun bildirme komutları

2 Kısa özet bölümü
(Bu bölüm kullanıcıya yazılımın hangi bölümlerinin ihtiyaç duyulan
yetenekleri sağladığına dair genel bir anlayış verir.)

3 Komutlar bölümü
(Her komut için aşağıdakileri sağlar…
(a) İşlevsel tarif
(b) Dikkat çekilen noktalar ve uyarılar
(c) İşlemler, aşağıdakiler dahil:
- Kurulum ve başlangıç
- Giriş işlemleri
- Beklenilen sonuçlar
(d) Olabilecek hatalar ve muhtemel nedenler)

4 Başvuru bölümü
(Her işlemi tanımla, aşağıdakiler dahil olmak üzere :
(a) İşlevsel tarif
(b) Dikkat çekilen noktalar ve uyarılar
(c) Biçimsel tarif, aşağıdakilerden yeri gelenler dahil olmak üzere:
- gerekli değişkenler
- isteğe bağlı değişkenler
- yoktan geçerli seçenekler
- sıra ve dilbilgisi
(d) Örnekler
(e) Olabilecek hatalar ve muhtemel nedenler
(f) Diğer işlemlere kestirme değinmeler)
Ek A Hata mesajları ve kurtarıcı işlemler
Ek B Sözlük
Ek C İçindekiler

***********************************************************************************

YAZILIM DEVİR BELGELERİ - SOFTWARE TRANSFER DOCUMENT(STD)

1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, Kısaltmalar, Deyimler
1.4 Referanslar

2 Kurulum İşlemleri

3 Uygulama İnşa İşlemleri

4 Kurulum Yapısı Unsurları Listesi

5 Kabul Sınama Rapor Özeti

6 Yazılım Sorun Raporları

7 Yazılım Değişiklik İstekleri

8 Yazılım Değişiklik Raporları
***********************************************************************************
***********************************************************************************
***********************************************************************************

Hayırlı olsun...