Capstone Brifi, Discovery ve Gereksinim Kaydı

Final Capstone, önceki modüllerde üretilen parçaları tek bir Arven Holding karar dosyasında sınar. Burada yeni bir müşteri keşfi yaptığını iddia etmiyorsun; eğitimde açılmış kanıtları, açık soruları ve yetki sınırlarını toparlıyorsun. Kanonik başlangıç yalnız yaklaşık 1.200 çalışan, İstanbul birincil veri merkezi, Ankara DR lokasyonu, VMware tabanlı sanallaştırma, yaklaşık 5–6 yıllık altyapı, Veeam kullanımı ve modernizasyon değerlendirmesidir. Sunucuların sayısı, veri büyümesi, iş yükü kritiklikleri, RPO/RTO, bütçe ve lisans hakları açıklanmış değildir. Önceki derslerin sabah raporu gecikmesi veya ay sonu yükü gibi örnekleri gerçek müşteri olgusu statüsüne yükseltme. Bu ders capstone’un ilk bölümü olarak bir bilgi kesiti ve Discovery/Requirement Register temelini kurar; sonraki dersler sizing, mimari, BoM, yönetici teklifi ve teknik savunmayı ekler. Yaklaşık 25 dakika kanıt taraması, 30 dakika gereksinim atölyesi ve 20 dakika çapraz kontrol ayır. Çıktı tarihli bir capstone charter, görüşme planı, kaynağa bağlı gereksinim kaydı ve açık risk/varsayım defteridir.

İlk kurul sorusunu 'hangi platformu alalım?' şeklinde yazarsan çözümü henüz doğrulanmamış bir sorunun içine kilitlersin. Bunun yerine hangi iş akışının neden modernizasyon istediğini, bugünkü maliyet ve riski kimin taşıdığını ve hangi sonuçla kararın başarılı sayılacağını araştır. GOV.UK discovery rehberi önerilmiş çözümü problem olarak yeniden çerçevelemeyi, varsayımları parçalamayı ve çözüm inşasından önce kullanıcı bağlamı ile kısıtları öğrenmeyi öğütler. Bu bir kamu hizmeti prosedürünü Arven’e dayatmak değil; yanlış varsayımla pahalı mimari kurmamak için soru disiplinidir. Capstone charter’ına sponsor rolü, teknik owner, operasyon/DR ve ticari karar merciini ayrı yaz. İsim veya kişi bilinmiyorsa rolü TBD ve doğrulama sorusu olarak bırak. Karar alanını da sınırla: mevcut altyapının yenilenmesi mi, belirli iş akışının güvenilirliği mi, daha geniş işletim dönüşümü mü? Bu üçü aynı kapsam değildir. Kapsam dışı alan, varsayım ve başarı ölçüsü taslak olarak işaretlenir; müşteri onayı olmadan kesinleşmez.

Discovery görüşmesini yalnız altyapı envanteri istemek için düzenleme. Önce iş sahibiyle kritik hizmet, kullanıcı etkisi, kesinti toleransı, bugünkü maliyet ve değişimin beklenen faydasını konuş. Ardından uygulama sahibiyle veri akışı, entegrasyon ve zamanlama; operasyon ekibiyle olay, yedek ve restore pratiği; güvenlikle erişim ve politika; ticari rolle bütçe, sözleşme, lisans ve satın alma yolunu ele al. Bir rolün cevabını diğerinin onayı sayma. Örneğin sanallaştırma yöneticisi kapasite tablosu sağlayabilir, fakat maliyet bütçesini veya RPO hedefini tek başına onaylayamayabilir. Sorular açık, ölçülebilir ve nötr olmalıdır: 'Kaç VM var?' sorusuna ek olarak 'hangi iş akışı, hangi pikte, hangi gözlem süresiyle zorlanıyor?' sor. RTO/RPO yalnız sayı olarak değil, etkilenen hizmet, veri kaybı anlamı ve kabul sahibiyle birlikte öğrenilir. Görüşme davetindeki amaç ve veri talebi açık olur; gizli üretim verileri ders materyaline taşınmaz.

Görüşme notu kanıt deposunun kendisi değildir. Her müşteri cümlesine tarih, söyleyen rol, doğrulama statüsü ve varsa belge/sistem kaynağı bağla. Alınan ölçümün hangi zaman penceresini kapsadığını yaz; tek anlık CPU grafiğini kalıcı kapasite ihtiyacı olarak yorumlama. Birbiriyle çelişen iki açıklama varsa 'müşteri kararsız' demek yerine farkı tanımla: iş birimi kabul edilebilir kesintiyi saatlerle anlatırken operasyon ekibi geçmişte dakikalık hedef varsaymış olabilir. Bu fark önemli bir Discovery çıktısıdır. Yetkili owner ile teyit edilmeden gereksinim kaydını APPROVED yapma. GOV.UK rehberindeki kullanıcı bağlamı ve kısıt analizi bu ayrımı destekler; Arven için birebir kamu hizmeti yöntemini kopyalamıyoruz. Toplanan bilgi mimariyi değiştirebileceğinden görüşme sırası yüksek etkili bilinmeyenlere göre önceliklenir. İlk turda on soru sorup hepsini kapatmaya çalışma: karar yolunu bloke eden üç soruyu, istenen kanıtı ve takip tarihini çıkar.

Discovery çıktısını Requirement Register’a dönüştürürken müşteri sözünü çözüm adından ayır. 'Yeni storage alınmalı' bir aday çözüm cümlesidir; 'ay sonu raporu iş sahibinin kabul ettiği sürede tamamlanmalı' ise ölçü ve kaynak gerektiren iş sonucu hipotezidir. Her satırın benzersiz ID’si, kaynak rolü ve tarih, iş amacı, fonksiyonel veya fonksiyonel olmayan türü, kabul ölçüsü, önceliği, statüsü, kısıtı, doğrulama yöntemi ve ownerı olur. Ölçü bilinmiyorsa hedef uydurma; 'eşik TBD, owner iş sahibi' yaz. Microsoft’un business-needs tasarım ilkesi mimari kararın iş gereksinimiyle gerekçelendirilmesini, fonksiyonel ve fonksiyonel olmayan ihtiyaçların ayrılmasını anlatır. NASA Systems Engineering Handbook ise gereksinimin üst ihtiyaç ve doğrulama ile iki yönlü izlenmesini önerir. Bu yöntemleri Arven eğitim dosyasına uyarlıyoruz; NASA kurumu Arven’in standart belirleyicisi değildir. Gereksinim, tasarımın ve testin geriye izlenebileceği kadar belirgin olmalı. 'Yüksek erişilebilirlik olsun' ölçüsüzdür; etkilenen akış, hizmet koşulu ve doğrulama henüz belirlenmemiştir.

Kayıtta KNOWN, CANDIDATE, ASSUMED, UNKNOWN ve APPROVED statülerini karıştırma. Açıklanmış VMware altyapısı KNOWN’dur; modernizasyon seçeneğinin hangi teknolojiye gideceği APPROVED değildir. Her gereksinim için 'bu doğru değilse hangi karar değişir?' sorusunu sor. Bir risk maddesi gereksinim kılığına girmiş olabilir: yedeklerin geri yüklenememesi endişesi kanıtlanmış arıza değil, test planı gerektiren risk/hipotezdir. Kabul kriteri ve doğrulama yöntemi birbirinden ayrı: 'rapor 10 dakikada biter' müşteri teyidi yoksa örnek eşiktir; 'temsili yükte zaman damgalı uçtan uca ölçüm' ise bir test yöntemidir. Çapraz izde iş amacı → REQ ID → risk/varsayım → aday mimari → deney/test → karar gösterilir. Birden çok çözüm aynı gereksinimi karşılayabilir. Gereksinim kaydı tedarik şartnamesine dönüşeceği için vendor özelliğini erken sabitlemek rekabeti ve teknik dürüstlüğü zedeleyebilir. Ders sonunda onay bekleyen satırları açık bırakmak başarısızlık değildir; bilginin durumunu doğru göstermek capstone’un ilk başarısıdır.

Capstone’un ilk karar kapısı, eksik bilgiyi görünür kılarak ikinci derse devretmektir. Varsayım gerçekleşmemiş bir koşulu sınanabilir biçimde ifade eder: örneğin 'ay sonu işlem yükü mevcut gözlemden anlamlı yüksek olabilir'. Risk, bu koşul gerçekleşirse iş veya tasarım kararına etkidir: yetersiz sizing, yanlış BoM veya desteklenmeyen kurtarma hedefi. UNKNOWN henüz elde edilmemiş olgudur; TBD ise owner ve tarihle açılmış doğrulama işidir. Aynı konu dört kayıtta yer alabilir ama statüler karışmamalı. Her varsayım için kanıt türü, doğrulama maliyeti ve hangi kararın duracağı yazılır. Her risk için olasılık yerine mümkünse etki, tetik, azaltım ve fallback tanımla; sayısal puan uydurmak yerine neden yüksek öncelikli olduğunu anlat. Kritik bilinmeyen RPO/RTO veya lisans hakları için müşteri görüşmesi, restore kanıtı, sözleşme incelemesi gibi ayrı faaliyetler gerekecektir. Bu işler kapanmadan sonraki derste yalnız koşullu mimari alternatifi kurulabilir.

Teslim paketinde tarihli bilgi kesiti, dört rolün görüşme soruları, en az üç REQ satırı, risk/varsayım defteri, kanıt istekleri ve karar yolunu bloke eden TBD listesi bulunur. Dosyanın her sayfası aynı vaka sürümünü kullanır; yeni yanıt geldiğinde v1’i silmek yerine v2 farkını kaydet. Bir requirement satırına yeni kaynak eklendiğinde risk, sizing ve ADR etkisi taranır. Microsoft’un mimari tasarım spesifikasyonu rehberi tasarımın açık iş ihtiyaçlarına köklenmesini, fonksiyonel ve fonksiyonel olmayan kararların belgelenmesini, alternatif ve test planlarının tutarlı tutulmasını önerir. Buradaki aktarım, henüz tasarım yapmadan önce tasarım ekibine güvenilir girdi hazırlamaktır. Capstone puanı güzel bir ürünü önceden seçmeye değil, hangi iddianın hangi kanıtla karar olabileceğini göstermeye dayanır. Son kontrol olarak başka bir öğrenciye dosyanı ver: hangi bilgi müşteri tarafından açıklanmış, hangisi eğitim hipotezi, hangi karar ertelenmiş sorularına kaynağa bakarak yanıt verebiliyor mu? Veremiyorsa kayıt hazır değildir.