Yazılım dünyasında en çok yanlış anlaşılan konulardan biri bence SDLC. Kulağa ders kitabından fırlamış gibi geliyor, evet. Ama işin aslı şu ki, bir projeyi batıran ya da toparlayan şey çoğu zaman koddan önce seçilen süreç oluyor. Geçen yıl, 2025’in Mart ayında İstanbul’daki küçük bir fintech ekibinde bunu birebir gördüm: ekip gerçekten yetenekli geliştiricilerden oluşuyordu, hepsinin CV’si sağlamdı, ama model seçimi yanlış olunca teslimatlar gecikti, testler birbirine girdi ve müşteri tarafı da “bu iş niye uzadı?” diye haklı olarak sormaya başladı (evet, doğru duydunuz). Haklıydılar da.
SDLC’yi basitçe yazılımın doğumdan yayına ve bakıma kadar geçen yolculuğu gibi düşünebilirsiniz. Hani çocuk büyütmek gibi değil de… biraz daha disiplinli, biraz daha az kaos içeren bir versiyon. Önce ne istediğinizi anlarsınız, sonra plan yaparsınız, tasarlarsınız, geliştirirsiniz, test edersiniz ve en sonunda canlıya alıp bakımını sürdürürsünüz. Ama her proje aynı değil. O yüzden tek bir model herkese uymaz — bu çok kritik bir nokta.
Ben editör masasında bu konuyu ilk kez ciddiye aldığımda 2023’teydim, Ankara’da çalışan bir SaaS ekibiyle sohbet ederken. Ekip Waterfall ile başlamıştı çünkü başlangıçta gereksinimler net görünüyordu. Sonra müşteri “şunu da ekleyelim” dedi… ve klasik hikâye başladı: planlar dağıldı, herkes birbirine baktı, kim ne yapacak belli değil. Açık konuşayım, orada sorun teknoloji değildi. Süreçti.
SDLC Nedir, Neden Bu Kadar Önemli?
Yani, SDLC. Software Development Life Cycle, bir düşüneyim… yazılım geliştirmeyi rastgele ilerleyen bir iş olmaktan çıkarıp düzene sokuyor. Bir nevi mutfakta tarif defteri gibi: malzemeler belli değilse yemek de tutmuyor. Yazılımda da ihtiyaçlar netleşmeden kod yazmaya dalarsanız sonradan geri dönüp sök-tak yapmanız kaçınılmaz oluyor — ve bu sök-tak işi hem sinir hem para yakıyor, inan.
Bir dakika — bununla bitmedi.
Bu çerçeve sadece büyük şirketler için değil. Küçük startup’larda da işe yarıyor çünkü kaynak kıtlığı tam da burada devreye giriyor; yanlış yapılan her adım hem para hem zaman eritiyor, hem de ekip moralini düşürüyor ki bunu sayıya dökmek zor. Etkisi çok somut. Kurumsal tarafta ise mesele başka: onay süreçleri, güvenlik kontrolleri. E peki, sonuç ne oldu? Ekipler arası bağımlılıklar işi bambaşka bir karmaşıklığa taşıyor.
Bana kalırsa SDLC’nin en güzel yani şeffaflık vermesi. Herkes “şu an neredeyiz?” sorusunun cevabını görebiliyor. Tabii kağıt üstünde süper duran bazı modeller pratikte biraz hantal kalabiliyor — onu da saklamayayım, sonradan “neden söylemedin?” demeyin.
Sürecin Temel Adımları
İster Waterfall kullanın ister Agile… temel iskelet pek değişmez. Gereksinim toplama, planlama, tasarım, geliştirme, test etme ve yayına alma/bakım aşamaları neredeyse her zaman var. Ama bu adımların sırası ve birbirine bağlanma biçimi modele göre ciddi şekilde farklılaşıyor — işte asıl fark orada çıkıyor. Bu konuyla ilgili Karpathy’nin Defteri SEO’yu Nasıl Düzeltiyor? yazımıza da göz atmanızı tavsiye ederim.
Mesela requirements kısmında ben çoğu ekipte aynı hatayı görüyorum. Herkes “zaten biliyoruz ne istediğimizi” deyip geçiyor, kimse belgelemiyor, kimse sormaya gerek duymuyor. Sonra üç hafta sonra ürün sahibi çıkıp başka bir şey kastettiğini söylüyor. O noktada işler biraz çorba oluyor (buna dikkat edin). hmm, biraz değil, epey çorba. Bu konuyla ilgili Wilmer’e Tool Calling Geldi: Yerel AI Akışı Değişiyor yazımıza da göz atmanızı tavsiye ederim.
- Gereksinim toplama: Kullanıcı ne istiyor?
- Planlama: Kim ne yapacak?
- Tasarım: Sistem nasıl görünecek? (bence en önemlisi)
- Geliştirme: Kod gerçekten yazılıyor mu? Evet.
- Test: Bozuk yerleri bulma faslı
- Kullanıma alma ve bakım: Canlıda olan sistemin ayakta tutulması
Klasik Modeller: Waterfall’dan V-Model’e
Waterfall Modeli
Cascading şelale mantığıyla çalışan Waterfall modeli doğrusal ilerler; bir aşama bitmeden diğerine geçilmez. Küçük ve gereksinimleri sabit projelerde fena değildir, hatta bayağı düzenlidir. En çok da regülasyonun ağır olduğu alanlarda dokümantasyon avantaj sağlar — denetçi geldiğinde “işte belgelerim” diyebilmek ayrı bir güven veriyor.
Ama gel gelelim, değişiklik seviyorsanız can sıkabilir. Müşterinin ortada fikir değiştirmesi halinde geriye dönmek pahalıya patlar. Ben bunu 2024’te İzmir’deki bir kurumsal entegrasyon projesinde yaşadım; iki küçük revizyon yüzünden takvim neredeyse iki katına çıktı. İki küçük revizyon. Düşünsenize.
Iterative Modeli
Şöyle ki, Iterative yaklaşımda ürün parça parça olgunlaşır. İlk sürüm mükemmel olmak zorunda değildir; önemli olan çalışıyor olmasıdır. Dürüst olayım, bu yaklaşımı seven ekiplerin çoğu. Pratik düşünür — “mükemmeli bekle, dünyayı kaçır” mantığından uzak insanlar bunlar. İlk versiyonla erken geri bildirim almak büyük artı, tartışmasız.
Bilmem anlatabiliyor muyum, Eksi tarafı mı? İyi planlanmazsa maliyet yavaş yavaş şişebilir çünkü her turda yeniden düzenleme yapmak gerekiyor, üstüne teknik borç birikmeye başlıyor, bir de bakıyorsunuz ne zaman kontrol kaybettiniz anlayamamışsınız. Yani hızlı başlamak kolaydır ama rotayı korumak ayrı beceri ister.
V-Model
Açık konuşayım, V-Model’de geliştirme ile test yan yana yürür; her geliştirme adımının karşısında bir doğrulama ayağı bulunur. Test kritikse bu model baya işe yarar çünkü hata kapısını erkenden kapatır. Erken. Sonradan değil.
// Basit eşleştirme fikri
requirement -> acceptance test
system design -> system test
architecture -> integration test
module design -> unit test
| Ana Model | Nerede Parlıyor? | Zayıf Nokta |
|---|---|---|
| Waterfall | Sabit gereksinimler | Düşük esneklik |
Daha Esnek Yaklaşımlar: Agile ve Spiral
Agile Modeli
Agile’ın gücü küçük parçalar halinde ilerlemesinden geliyor; sprint mantığı sayesinde ekip elindeki işi kısa döngülerde bitirip geri bildirim alıyor. Bir arkadaşım Şubat 2025’te Kadıköy’de kurduğu e-ticaret girişiminde tamamen Agile’a geçtiğinde ilk iki ay kaos vardı — toplantılar karışıktı, kim neyi sprint’e alacak belli değildi, herkes birbirine bakıyordu — ama üçüncü aydan sonra teslim hızları ciddi şekilde toparlandı. Bana inanamadılar resmen. Burada önemli nokta şu: Agile özgürlük veriyor ama disiplinsiz bir ekibe verilince sadece toplantı üretir. Gerçekten.
Eksi taraf olarak dokümantasyon bazen ihmal ediliyor; sonradan yeni gelen kişi sistemi anlamakta zorlanabiliyor, “bu ne yapar, neden yazılmış” diye saatlerce kaybolabiliyor. O yüzden “her şeyi çevik yapıyoruz” demek yetmiyor… ölçülebilir ritim gerekiyor, somut çıktılar gerekiyor. Daha fazla bilgi için Skyrim’in Havasını Değiştiren Küçük Ama Etkili Mod yazımıza bakabilirsiniz. Yapay Zekâ Kod Yazıyor Ama İsim Vermek Hâlâ Zor yazımızda da bu konuya değinmiştik. Portfolyonuz Mükemmel Görünse de Neden Eski Kalır? yazımızda da bu konuya değinmiştik.
Spiral Modeli
Yani, Bence Spiral model, risk yüksekse değer kazanıyor. Neyse özellikle sağlık teknolojileri veya finans gibi alanlarda risk analizi oyunun merkezine oturuyor; her döngüde riskler gözden geçiriliyor. Ürün buna göre şekilleniyor. Bu yaklaşım büyük projelerde rahatlatıcı olabilir çünkü bilinmeyeni küçültüyor —. Fiyat etiketi de ona göre kabarık oluyor, açık konuşayım.
Küçük startup için fazla ağır gelebilir, orada boğulursunuz (ciddiyim). Ama enterprise seviyede güven veren tarafları var. Yani doğru yerde kullanılırsa güçlüdür… yanlış yerdeyse bütçe eritir.
En iyi SDLC modeli diye tek cevap yoktur; doğru seçim genelde takımın olgunluğu ile projenin belirsizlik seviyesinin kesiştiği yerde çıkar.
Peki Hangi Durumda Hangisi Seçilmeli?
Lafı gevelemeden söyleyeyim:
- Sabit ihtiyaçlar varsa: Waterfall ya da V-Model iş görür.
- Sık değişen ürünlerde: Agile daha rahat nefes aldırır.
- Büyük risk içeren işlerde: Spiral mantıklı olur.
- Kademeli iyileştirme istendiğinde: Iterative iyi seçenek olur.
E tabi karar verirken yalnızca metodolojiye bakmıyorum ben. Teknik borç var, ekip deneyimi var, müşterinin sabrı var — ki bunu küçümsemeyin, sabırsız müşteri her modeli çökertir — test otomasyonu var, bütçe var… bunların hepsi tabloya giriyor. Bir startup’ta hızlı öğrenme öncelikken, kamu kurumunda izlenebilirlik ön plana çıkabiliyor. Aynı araç herkes için uygun değil. Bu kadar basit.
Açıkçası, “Kağıt üstünde güzel” görünen model bazen sahada hayal kırıklığı yaratıyor. Mesela geçmişte QA olmayan küçük bir ekipte Agile denediler; sprint’ler doldu taştı ama kabul kriterleri yazılmadığı için kimse “bitmiş” sayacağını bilmiyordu. Sorun modelde değil gibiydi ama aslında eksik uygulamaydı. Farkı görmek lazım bu ikisi arasında.
Durun, bir saniye.
Bir dakika, şunu da ekleyeyim. Ne seçerseniz seçin, ilk günden itibaren iletişim kanalı kurmak şart. Slack olur, Teams olur, eski usul toplantı odası olur… ama görünürlük yoksa süreç körleşiyor. Gözlerimle gördüm bunu defalarca.
| Amaç | Kilit Sorun | Daha Uygun Model |
|---|---|---|
| Maliyet kontrolü | İhtiyaçlar sabit | Waterfall |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
