Zeynep Dandin
Project Manager
27 Ekim 2026
SDLC, İngilizce “Software Development Life Cycle” ifadesinin kısaltmasıdır. Türkçede yazılım geliştirme yaşam döngüsü ya da kısaca yazılım yaşam döngüsü olarak geçer. Bir yazılım fikrinin planlanmasından kullanıcıya ulaşmasına ve sonrasında bakımına kadar uzanan tüm adımları tanımlayan çerçevedir.
Bu yazıda SDLC’nin ne olduğunu, altı temel aşamasını, en çok kullanılan yazılım geliştirme modellerini ve bu döngünün gerçek bir mobil uygulama projesinde nasıl işlediğini anlatıyoruz.
SDLC Nedir?
SDLC, bir yazılım projesinin hangi adımlardan geçeceğini, her adımda kimin ne yapacağını ve bir adımın ne zaman bitmiş sayılacağını tanımlayan süreç çerçevesidir. Amaç, yazılımı tahmin edilebilir bir sürede, bütçeyi aşmadan ve istenen kalitede teslim etmektir.
Çerçevenin değeri, belirsizliği azaltmasından gelir. Süreç tanımlı olmayan bir projede gereksinimler geç netleşir, test sona sıkışır ve teslim tarihi kayar. SDLC bu riskleri baştan görünür kılar.
Önemli bir ayrım var: SDLC bir yöntem değil, bir çerçevedir. “Şelale mi, agile mı?” sorusu SDLC’nin içindeki model seçimiyle ilgilidir. Hangi modeli seçerseniz seçin, aşağıdaki aşamalar bir biçimde yaşanır.
SDLC Neden Önemlidir?
Yaşam döngüsünü bilinçli yönetmek üç somut fayda sağlar:
Öngörülebilirlik: Her aşamanın çıktısı belli olduğu için süre ve maliyet daha gerçekçi planlanır.
Kalite: Test ve gözden geçirme, projenin sonuna bırakılmaz. Hatalar erken ve ucuz yakalanır.
Ortak dil: Yönetici, tasarımcı, geliştirici ve müşteri aynı aşama adlarıyla konuşur, beklentiler hizalı kalır.
Bir hatanın maliyeti, bulunduğu aşamayla birlikte artar. Gereksinim aşamasında bir cümleyle düzeltilebilecek bir yanlış anlaşılma, yayından sonra aylarca süren bir yeniden yazıma dönüşebilir.
SDLC Aşamaları
Farklı kaynaklar aşamaları beş ile yedi arasında sayar. Aşağıdaki altı adım en yaygın kullanılan ayrımdır.
1. Planlama
Projenin neden yapıldığı, kime hizmet ettiği, kapsamı, bütçesi ve takvimi bu aşamada netleşir. Fizibilite sorusu da burada sorulur: Bu ürün teknik, mali ve operasyonel olarak yapılabilir mi? Çıktı genellikle proje planı ve kapsam belgesidir.
2. Gereksinim Analizi
İş hedefleri, kullanıcı ihtiyaçları ve teknik kısıtlar yazılı gereksinimlere dönüştürülür. İyi bir gereksinim ölçülebilir olmalıdır. “Hızlı açılsın” yerine “ana ekran 2 saniyenin altında yüklensin” yazılır. Bu dönüşümü iş hedeflerini teknik gereksinimlere dönüştürme yazımızda adım adım anlattık. Ürünün gerçekten çözmesi gereken sorunu netleştirmek için ürün keşfi adımları da bu aşamaya girer.
3. Tasarım
Hem kullanıcının gördüğü arayüz hem de sistemin teknik mimarisi bu aşamada tasarlanır. Arayüz tarafında akışlar, ekranlar ve tasarım sistemi hazırlanır. Teknik tarafta veritabanı, servis yapısı, API’ler ve güvenlik yaklaşımı belirlenir. Çıktılar tasarım dosyaları ve mimari dokümandır.
4. Geliştirme
Tasarım koda dönüşür. Ekip, işi küçük parçalara böler, kodu sürüm kontrol sisteminde tutar ve birbirinin kodunu gözden geçirir. Bir projenin en uzun aşaması çoğunlukla budur, ancak önceki üç aşama iyi yapılmışsa en az sürprizli aşama da odur.
5. Test
Yazılımın gereksinimleri karşılayıp karşılamadığı doğrulanır. Birim testleri küçük kod parçalarını, entegrasyon testleri parçaların birlikte çalışmasını, kabul testleri ise ürünün müşterinin beklentisini karşılayıp karşılamadığını kontrol eder. Performans ve güvenlik testleri de bu aşamanın parçasıdır.
6. Yayın ve Bakım
Ürün canlıya alınır. Mobil uygulamada bu, App Store ve Google Play’e gönderim ve onay sürecini de kapsar. Yayın bir son değil, yeni bir döngünün başlangıcıdır: hata düzeltmeleri, güvenlik güncellemeleri, işletim sistemi uyumluluğu ve yeni özellikler bakım ve destek kapsamında sürer.
Yazılım Geliştirme Modelleri
Aşamalar sabittir, ama ekibin bu aşamaları nasıl sıraya koyduğu modele bağlıdır. En çok kullanılan modeller şunlardır.
Şelale Modeli (Waterfall)
Aşamalar birbiri ardına, geri dönüşsüz akar. Bir aşama bitmeden diğeri başlamaz. Gereksinimler baştan net ve değişmeyecekse, örneğin düzenlemeye bağlı bir kurumsal sistemde, öngörülebilir ve belgelenmiş bir yol sunar. Dezavantajı, ürünü kullanıcıya geç göstermesi ve sonradan gelen değişikliğe kapalı olmasıdır.
Agile (Çevik) Model
Proje, iki ila dört haftalık kısa döngülere (sprint) bölünür. Her döngüde planlama, geliştirme ve test küçük bir ölçekte tekrarlanır ve çalışan bir ürün parçası ortaya çıkar. Değişen önceliklere uyum sağlar. Scrum ve Kanban en bilinen uygulamalarıdır. Seçim konusunda Agile ve Waterfall karar rehberimize bakabilirsiniz.
Spiral Model
Her döngüde risk analizine ağırlık veren, yinelemeli bir modeldir. Büyük, pahalı ve riski yüksek projelerde, riskin her turda yeniden değerlendirilmesi gerektiğinde tercih edilir. Küçük projeler için gereğinden ağır kalır.
V Modeli
Şelalenin test odaklı varyantıdır. Her geliştirme aşamasının karşısına bir test aşaması konur. Güvenliğin kritik olduğu, hatanın kabul edilemez olduğu sistemlerde kullanılır.
Model | Yapı | Değişikliğe uyum | Uygun proje |
Şelale | Doğrusal, aşama aşama | Düşük | Kapsamı sabit, belgelenmiş projeler |
Agile | Kısa, tekrarlayan döngüler | Yüksek | Ürün odaklı, değişen öncelikli projeler |
Spiral | Risk odaklı döngüler | Orta | Büyük ve riskli projeler |
V modeli | Test eşlemeli doğrusal akış | Düşük | Güvenlik ve güvenilirlik kritik sistemler |
Bugün çoğu ürün ekibi tek bir modeli saf haliyle uygulamaz. Genel çerçeveyi agile tutup, ödeme ya da güvenlik gibi kritik parçalarda şelale benzeri bir netlik arar. Süreci hızlandıran CI/CD pratikleri için DevOps nedir yazımıza göz atabilirsiniz.
Mobil Uygulama Projesinde SDLC
Mobil uygulama geliştirmede aşamalar aynıdır, ancak mobil dünyaya özgü kararlar eklenir. Neon Apps olarak 2019’dan beri iOS, Android ve çapraz platform projeleri teslim ediyoruz. Pratikte gördüğümüz akış şöyledir:
Keşif: Hedef kitle, rakipler ve ilk sürümün kapsamı belirlenir. Küçük başlayıp öğrenmek için yazılımda MVP yaklaşımı sıkça kullanılır.
Tasarım: Platform kurallarına (iOS ve Android arayüz yönergeleri) uygun akışlar ve prototipler hazırlanır. Detaylar için mobil uygulama tasarımı rehberimize bakabilirsiniz.
Geliştirme: Native ya da çapraz platform seçimi yapılır, backend ve API’ler uygulamayla paralel ilerler.
Test: Farklı cihaz ve işletim sistemi sürümlerinde test yapılır. Mobil uygulama güvenliği bu aşamada ayrıca denetlenir.
Yayın: Mağaza gereklilikleri, gizlilik beyanları ve onay süresi takvime dahil edilir. Mağaza onayı, tek başına tahmin edilmesi zor bir adımdır.
Bakım: Yeni işletim sistemi sürümleri ve kullanıcı geri bildirimleri sonraki döngüyü belirler.
Sürecin tamamını bir proje üzerinden görmek isterseniz mobil uygulama geliştirme şirketi aslında ne yapar yazımız bu soruya ekip gözüyle bakıyor.
SDLC Uygulanırken Sık Yapılan Hatalar
Gereksinim aşamasını atlamak: Hızlı başlama isteği, sonradan en pahalı düzeltmeleri doğurur.
Testi sona bırakmak: Test, geliştirmeyle birlikte yürütülmezse hatalar birikir ve teslim kayar.
Belgelemeyi hiç yapmamak: Bir ekip değiştiğinde bilgi de gider.
Bakımı bütçeye koymamak: Yayın sonrası güncelleme maliyeti çoğu zaman planlanmaz.
Modeli proje yapısına uydurmamak: Kapsamı değişken bir ürünü katı bir şelale planına zorlamak gecikme üretir.
Yazılımınızın mevcut durumunu bu çerçevede değerlendirmek isterseniz yazılım denetimi yazımız hangi sorunların ortaya çıkması gerektiğini anlatıyor.
Güvenli SDLC
Güvenlik, sürecin sonunda işaretlenen bir kutu olmamalıdır. Güvenli SDLC, her aşamaya bir güvenlik adımı ekler:
Gereksinim: Veri koruma, kimlik doğrulama ve uyumluluk ihtiyaçları baştan yazılır.
Tasarım: Tehdit modellemesi yapılır ve güvenli bir mimari seçilir.
Geliştirme: Güvenli kodlama kurallarına uyulur, kullanılan kütüphaneler zafiyet için taranır.
Test: Güvenlik testleri ve sızma testleri yapılır.
Bakım: Yeni zafiyetler yamalanır, olaylar izlenir.
Mobil projelerde en sık görülen tehditleri ve önlemlerini mobil uygulama güvenliği yazımızda anlattık.
SDLC En İyi Uygulamaları
Ölçülebilir gereksinim yazın. Belirsiz hedefler sonradan yeniden iş çıkarır.
Sürekli test edin. Testleri otomatikleştirin ki her değişiklik kontrol edilsin.
Kapsamı görünür tutun. Değişiklik taleplerini kaydedin ve açıkça karara bağlayın.
Kritik kararları belgeleyin. Ekip değiştiğinde bilgi kalmalıdır.
Kod incelemesi yapın. İkinci bir göz hataları yakalar ve bilgiyi yayar.
Bakımı ilk günden planlayın. Güncelleme, barındırma ve destek için bütçe ayırın.
Yayından sonra ölçün. Analitik ve geri bildirim bir sonraki adımı belirlesin.
SDLC ve DevOps İlişkisi
DevOps, SDLC’nin yerine geçmez, onu hızlandırır. Geliştirme ve operasyon ekiplerini birleştirir, kodun test edilip canlıya alınmasını otomatikleştirir. Böylece “geliştirme bitti, şimdi yayın bekliyor” gecikmesi ortadan kalkar. Küçük ve sık sürümler, hatayı bulmayı ve geri almayı da kolaylaştırır. Bu yaklaşımı kurmak isteyen ekipler için DevOps nedir yazımız iyi bir başlangıçtır.
SDLC Metrikleri: Süreç Çalışıyor mu?
Bir sürecin işe yarayıp yaramadığını hissle değil ölçümle anlarsınız. SDLC’de en sık izlenen göstergeler şunlardır:
Teslim süresi: Bir fikrin ya da değişikliğin canlıya çıkması ne kadar sürüyor?
Hata oranı: Yayından sonra bulunan hata sayısı, yayından önce bulunanlara göre ne durumda?
Sürüm sıklığı: Ekip ne sıklıkla güvenle yayın yapabiliyor?
Kapsam değişimi: Plana sonradan eklenen iş ne kadar ve neden eklendi?
Kullanıcı geri bildirimi: Yayınlanan özellikler gerçekten kullanılıyor mu?
Bu göstergelerden bir ya da ikisiyle başlayın. Çok fazla metrik takip etmek, hiçbirini takip etmemek kadar etkisizdir.
SDLC’de Roller
Her aşamanın bir sahibi olmalıdır. Ürün sahibi neyin yapılacağına, tasarımcı kullanıcının neyi nasıl deneyimleyeceğine, geliştirici nasıl kurulacağına, test uzmanı ise bunun doğru çalışıp çalışmadığına odaklanır. Proje yöneticisi ise bu parçaları takvim, bütçe ve iletişim açısından bir arada tutar. Küçük ekiplerde bir kişi birkaç rolü üstlenebilir, ancak sorumlulukların kime ait olduğu yine de açık olmalıdır. Rol belirsizliği, gecikmelerin en sık nedenlerinden biridir.
SDLC’de Dokümantasyon
Yaşam döngüsünün her aşaması bir belge üretmelidir, ancak bunun uzun olması gerekmez. Planlamadan kapsam özeti, gereksinimlerden ölçülebilir madde listesi, tasarımdan ekran akışları ve mimari şema, testten test senaryoları, yayından sürüm notları çıkar. Amaç, ekibe yeni katılan birinin ya da bir yıl sonra projeye dönen birinin neyin neden yapıldığını anlayabilmesidir. Kısa, güncel ve ulaşılabilir belge, uzun ama kimsenin okumadığı belgeden daha değerlidir. Agile ekiplerde belgeler de küçük parçalar halinde, işle birlikte güncellenir.
Projeniz için süreci birlikte kurmak isterseniz özel yazılım geliştirme hizmetimizi inceleyebilir ya da bir ön görüşme planlayabilirsiniz.
