Arven Holding Vaka Dosyası ve Kanıt Durumları

Arven Holding sürekli vaka, tek derslik bir hikâye değil önceki 23 modülde toplanan görüşme, gereksinim, mimari ve doğrulama izlerini aynı müşteri kararı üzerinde birleştirme çalışmasıdır. Vakanın güvenli başlangıç açıklaması sınırlıdır: yaklaşık 1.200 çalışan, İstanbul'da birincil veri merkezi, Ankara'da DR lokasyonu, VMware tabanlı sanallaştırma, yaklaşık 5–6 yıllık altyapı, Veeam kullanımı ve modernizasyon değerlendirmesi. Bunları kesin konfigürasyon veya satın alma onayı sanma. 'Yaklaşık' sayılar tahmin aralığıdır. İş yükü, RPO, kapasite, lisans hakkı, bütçe ve karar yetkilisi bu başlangıçtan çıkarılamaz. Daha önceki eğitim alıştırmalarında kullanılan ERP ölçüsü veya POC sayısı örnek senaryodur; bu modülün açıklanmış müşteri gerçeği sayılmamalıdır. Bu ayrım özellikle önemlidir çünkü bir ödevde kurgulanan sayı başka derste fark edilmeden 'resmî müşteri şartı'na dönüşebilir. Yaklaşık 28 dakika anlatı, 29 dakika dosya uygulaması ve 15 dakika kontrol planla. Dersin çıktısı açıklanmış gerçekler, çalışma varsayımları, bilinmeyenler ve açık doğrulama işlerini ayıran Arven vaka dosyasıdır.

İlk kayıt yalnız açıklanmış olguyu ve kaynağını taşısın. 'İstanbul veri merkezi' konum bilgisidir; tesis güç kapasitesi, yangın zonu veya gecikme değeri değildir. 'Ankara DR lokasyonu' fiziksel alternatif olduğunu düşündürür ama üretimden ne kadar uzak, hangi bağımlılığa sahip veya çalışır durumda olduğu henüz bilinmez. 'VMware tabanlı' mevcut platform ailesi hakkında işarettir; sürüm, destek hakkı veya gelecekte aynı vendor ile devam etme şartı değildir. 'Veeam kullanımı' yedekleme ürününü bildirir, geri yükleme testi ve immutable kopya durumunu kanıtlamaz. Altyapının 5–6 yıllık olması yenileme gerekçesini araştırmayı başlatır; her bileşenin ömrünün dolduğu anlamına gelmez. Modernizasyon değerlendirmesi bütçe onayı veya RFP kararı değildir. Bu yedi satırın her biri hangi müşteri belgesinden ya da bu eğitim için kanonik vaka açıklamasından geldiğini açıkça göstermelidir. Öğrenen bu dosyayı sonraki modüllerde değişen iddialarla günceller, fakat kabul edilmiş eski kaydı sessizce silmez. Kaynak sürümü, tarih ve değiştiren kişi izlenir.

Vaka dosyasında dört temel durum kullan: KNOWN yalnız kaynağı doğrulanmış ve kapsamı belirli bilgi; ASSUMED çalışmayı ilerletmek için açıkça işaretlenmiş hipotez; UNKNOWN henüz veri veya yanıt yok; TBD sorusu ve sorumlusu belirlenmiş fakat karar bekleyen konu. Örneğin Arven'in iki lokasyonu KNOWN olabilir; lokasyonlar arasında yeterli bant genişliği olduğu ASSUMED bile olamazsa UNKNOWN kalır. 'Ağ ekibi bağlantı ölçümünü 12 Ekim'e kadar paylaşacak' tarihli satır TBD olur; tarih yalnız vaka alıştırmasıdır, gerçek müşteri taahhüdü değildir. Varsayım her zaman gerekçe, doğrulama yöntemi, owner, son tarih ve yanlış çıkarsa etkilenen karar içerir. Bilinmeyeni sıfır yazmak sizing'i yanıltır. TBD'yi sırf çok bekledi diye gerçek sayma. Discovery'de müşteriye hangi iş sonucunu, kısıtı ve karar ölçütünü sormak gerektiğini belirle. GOV.UK discovery rehberi çözüm varsayımını problem olarak yeniden çerçevelemeyi ve gerçek kullanıcı ihtiyacını araştırmayı önerir; bu kamu hizmeti bağlamından genel öğrenme ilkesi alınır, Arven alım prosedürü olarak sunulmaz. Vaka boyunca doğru 'daha fazla bilgi gerekli' kararı değerli olabilir.

Bilgi durumu değiştiğinde nedenini ve eski kaydı koru. Bir stakeholder 'RPO 30 dakika' derse görüşme notu, konuşan rol, soru bağlamı ve teyit durumunu kaydet; bu tek söz resmî şartnameyle çelişiyorsa karar makamını sor. Müşterinin imzalı açıklaması veya geçerli zeyilnamesi gelirse ilgili requirement ID, risk ve mimari karar bağlantısı güncellenir. Kaynak belgesi bulunamıyorsa duyumu ASSUMED olarak gizlemeyip teyitsiz görüşme notu veya UNKNOWN say. Teknik belgeyle iş hedefi çatıştığında belge hiyerarşisini ve geçerlilik tarihini incele. Örneğin eski HLD'deki kapasite sayısı güncel ölçüm olmadan bugünkü BoM'un temel girdisi olamaz. Microsoft Learn ADR rehberi kararların bağlamını, alternatiflerini, gerekçelerini ve sonuçlarını tutmayı; karar değişirse önceki kaydı silmek yerine yenisinin onu değiştirdiğini göstermeyi önerir. Bu ilke vaka defterinde de geçerlidir. Sonuç: her satırın 'şu anda ne biliyoruz?' sorusuna ve 'bir sonraki karar için ne eksik?' sorusuna ayrı cevabı vardır.

Arven vaka dosyası yalnız olay kronolojisi değil karar zinciridir. Bir iş hedefi önce müşteri cümlesine, oradan gereksinim ID'sine, kanıt veya varsayıma, mimari seçeneğe, BoM ve lisans sonucuna, doğrulama testine ve yetkili karara bağlanır. Zincirin herhangi bir halkası koparsa düzgün görünen mimari yanlış probleme yanıt verebilir. Örneğin 'sabah ERP raporu geç kalıyor' müşteri problemi; ölçülmüş pencere henüz yoksa 15 dakika hedefi gereksinim değildir. Önce gecikmenin iş etkisini ve başarı saatini sor, sonra iş yükünü ölç, ardından çözüm seçeneklerini kıyasla. NASA Systems Engineering Handbook gereksinimlerin üst düzey ihtiyaçlarla iki yönlü izlenebilmesini ve varsayımların baseline öncesi doğrulanmasını vurgular. NASA'nın uzay sistemi bağlamındaki kuralını Arven'e hukuk veya teknik standart diye taşımıyoruz; izlenebilir karar düşüncesini kullanıyoruz. Bir alt tasarım girdisinden müşteri ihtiyacına geri yürüyebilmelisin. Tersine, müşteri ihtiyacından hangi testin kanıt sağlayacağını bulabilmelisin. Bu dersin çalışma kâğıdı tek bir tercih için bu iki yönlü yolu görünür kılar.

İki kaynak çelişirse birini sessizce seçme. Örneğin görüşmede 'mevcut sanallaştırmayı koruyalım' denmiş, teknik şartnamede açık platform bağımsızlığı istenmiş olabilir. Hangisi geçerli, kim konuştu, karar yetkisi kimde ve hangi tarihte hangi doküman yayınlandı sor. Her çelişki bir etki satırı açar: gerekirse mimari A/B, lisans, veri taşınabilirliği, maliyet ve test planı değişir. Microsoft ADR rehberi karar değişikliklerinde yeni kaydın eskisini supersede etmesini önerir; Arven vaka defterinde de revizyonlu karar izi tutulur. Bir çıkarım artık geçerli değilse tarihi, nedeni ve bağlı artefaktları işaretle. Kullanıcı eski kararı neden verdiğini görebilmeli. Kapsam dışı varsayımlar risk kaydına gider; yüksek etkili UNKNOWN bilgi kapanmadan koşulsuz teklif verilmez. Bu eğitimde gerçek vaka motoru ve öğrenciye özel unlock henüz uygulanmadığından, ders yalnız başlangıçta güvenli açıklanmış olguları ve açıkça kurgusal alıştırma senaryolarını kullanır. Gizli vaka bilgisi görünümde saklanıp tarayıcıya gönderilmez.

Arven sürekli vaka defteri beş bağlı kayıt tutar: açıklanmış olgular ve kaynakları; gereksinim ve açık sorular; varsayım/risk; karar ve alternatif; doğrulama kanıtı. Tek dosyada birleştirebilirsin ama statüler ve kimlikler ayrı kalmalı. İlk sürümde açıklanmış çekirdeği gir; kapasite, lisans, RPO ve bütçe bilinmiyor olarak kalsın. Sonra yalnız eğitim alıştırması için bir ERP gecikmesi hipotezi yaz ve başlığına 'senaryo varsayımı' ekle. Bu sayı veya koşulu başka modülün müşteri gerçeği gibi kopyalama. Her kayıt için ID, tarih, kaynak veya görüşme, geçerlilik, owner, sonraki doğrulama ve etkilenen karar sütunları oluştur. Özellikle bir varsayım yanlış çıkarsa hangi HLD, BoM, teklif veya POC satırının yeniden açılacağını belirt. Bilgi güvenliği açısından ders herkese açık yerel kurgusal içerikle sınırlıdır; gelecekte öğrenciye özel açılan vaka gerçekleri ayrı yetkilendirme katmanında tutulmalıdır. Bu uygulama o motorun hazır olduğunu iddia etmez. Dersin sonucu, bir sonraki vaka dersinde discovery ve mimari kararların güvenle eklenebileceği boşlukları dürüst gösteren ilk kayıt sürümüdür.

Defteri bir arkadaşınla çapraz incele. İlk kişi 'bu sayı nereden geldi?' diye sorar, ikinci kişi 'yanlış çıkarsa hangi karar değişir?' diye sorar. Kaynağı olmayan ama tasarımda kullanılan satır yüksek risk olarak işaretlenir. Yetkili müşteri teyidi bekleyen ifade, tek bir olumlu toplantı yorumu yüzünden KNOWN'a yükselmez. Tersine, geçmişte doğrulanmış bir bilgi yeni tarihli belgeyle geçersiz olabilir; eski kaydı koruyup yeni sürümü bağla. Güncel veri yokken çözüm seçme baskısı oluşursa üç seçeneği açıkça sun: hedefli discovery ile belirsizliği kapat; aralıklı/koşullu tasarım üret; risk çok yüksekse kararı ertele. İyi pre-sales çalışması bütün kutuları doldurmak değil, karar için kritik boşlukları önceliklendirmektir. Bu modülün sonraki dersinde vaka zincirini discovery, mimari ve ticari karar bağımlılıklarıyla derinleştireceksin. Son değerlendirmede yalnız bilgiler değil, hangi kanıtla hangi kararın değiştiği açıklanmalıdır. Defterde 'Need More Information' bir başarısızlık değil, kanıt sınırını koruyan geçerli bir ara karardır.