Bir yazılım projesine başlarken en sık duyulan iki cümle şudur: "Ne zaman biter?" ve "Neden bu kadar uzadı?" İkisinin de cevabı büyük ölçüde projenin nasıl yürütüldüğünde, yani yazılım geliştirme sürecinde saklıdır. Süreç belirli değilse herkes farklı bir takvim, farklı bir kapsam ve farklı bir "bitti" tanımı hayal eder; belirliyse hangi aşamada olunduğu, kimden ne beklendiği ve işin ne zaman teslim edileceği baştan bellidir.
Bu rehberde yazılım geliştirme sürecinin (SDLC) ne olduğunu, yedi aşamasını, şelale, çevik ve Scrum gibi modellerin farkını, bir sprintin nasıl işlediğini, sprint hızına bakarak teslim tarihinin nasıl tahmin edildiğini, sürekli teslimin (CI/CD) yazılımı nasıl güvenli yayına aldığını ve hangi projede hangi modelin uygun olduğunu anlatıyoruz. Teknik bilgi gerekmez; yazılım yaptırmayı ya da yönetmeyi düşünen herkes için yazıldı.
Yazılım Geliştirme Süreci (SDLC) Nedir?
Yazılım geliştirme süreci, bir yazılımın fikirden canlıya ve sonrasında bakıma kadar hangi aşamalardan geçeceğini, her aşamada neyin üretileceğini ve kimin sorumlu olacağını tanımlayan çalışma düzenidir. İngilizce adı Software Development Life Cycle'dır, kısaca SDLC; Türkçede "yazılım geliştirme yaşam döngüsü" olarak da geçer.
Süreç bir kâğıt işi değildir; üç soruya cevap verir: Ne yapıyoruz ve neden? Hangi sırayla ve hangi çıktıyla ilerliyoruz? Bir aşamanın bittiğini nasıl anlıyoruz? Bu üç cevap yazılı olduğunda hem iş tarafı hem geliştirme ekibi aynı resme bakar; aksi hâlde proje, kişilerin hafızasına ve iyi niyetine kalır.
Yazılım Geliştirme Yaşam Döngüsünün Aşamaları Nelerdir?
Yazılım geliştirme yaşam döngüsü yedi aşamadan oluşur: planlama, gereksinim analizi, tasarım, geliştirme, test, yayın ve bakım. Aşama adları kaynağa göre biraz değişse de iş aynıdır: ne yapılacağını belirle, nasıl yapılacağını tasarla, yap, doğrula, yayına al ve çalışır tut.
| Aşama | Ne yapılır? | Çıktı |
|---|---|---|
| 1. Planlama | Hedef, fizibilite, kapsam, bütçe ve takvimin ilk çerçevesi | Proje tanımı, ilk kapsam |
| 2. Analiz | Kullanıcı rolleri, mevcut süreç, gereksinim ve kabul kriterleri | Gereksinim belgesi |
| 3. Tasarım | Ekran ve akış tasarımı, mimari, veri modeli, entegrasyon tasarımı | Prototip, mimari belgesi |
| 4. Geliştirme | Kodlama, birim testleri, kod gözden geçirme, entegrasyonlar | Çalışan yazılım parçaları |
| 5. Test | İşlev, performans, güvenlik ve kabul testleri; hata düzeltme | Test raporu, onaylı sürüm |
| 6. Yayın | Canlıya alma, veri aktarımı, eğitim, geri dönüş planı | Canlı sistem |
| 7. Bakım | İzleme, hata düzeltme, güncelleme, yeni özellik | Yeni sürümler |
Her aşamanın ayrı bir uzmanlık alanı vardır ve ayrı bir rehberi yazılabilir; biz bunların birkaçını ayrı yazılarda ele aldık. Gereksinim analizinin adımlarını yazılım gereksinim analizi nasıl yapılır yazısında, proje planı ve kritik yolu proje planı nasıl hazırlanır yazısında, testi yazılım testi nasıl yapılır yazısında, bütçeyi yazılım projesi maliyeti nasıl hesaplanır yazısında bulabilirsiniz.
Okumanızı öneririz: Proje sürecimiz: analizden canlıya adım adım
Yazılım Geliştirme Modelleri Nelerdir?
Yazılım geliştirme modeli, bu yedi aşamanın hangi sırayla ve hangi parçalarla yürütüleceğini belirler. Şelale modeli aşamaları sırayla ve bir kez uygular; çevik (agile) modeller aynı aşamaları kısa döngülerle, küçük parçalar için defalarca tekrarlar; sürekli teslim yaklaşımı ise yayını otomatikleştirerek bu döngüleri daha da sıklaştırır.
| Başlık | Şelale | Çevik (Scrum, Kanban) | Sürekli teslim (CI/CD) |
|---|---|---|---|
| Yapı | Aşamalar sırayla, bir kez | Kısa döngüler, her döngüde tüm aşamalar | Her değişiklik otomatik test edilip yayına hazırlanır |
| Teslim | Sonda tek büyük teslim | Her döngü sonunda çalışan sürüm | Günlük ya da daha sık küçük yayın |
| Değişikliğe uyum | Zor; değişiklik pahalı | Kolay; öncelikler her döngüde yeniden sıralanır | Çok kolay; küçük adımlar, hızlı geri dönüş |
| Müşteri katılımı | Başta ve sonda | Her döngüde gözden geçirme | Sürekli geri bildirim ve ölçüm |
| Belgeleme | Ağır, baştan | Gerektiği kadar, hafif | Otomasyon kendi kendini belgeler |
| Uygun olduğu durum | Gereksinim sabit ve net, değişiklik beklenmiyor | Gereksinim zamanla netleşiyor, geri bildirim değerli | Sık yayın yapılan, canlıda çalışan ürünler |
Çevik yaklaşımın temelleri 2001'de yayımlanan Çevik Yazılım Geliştirme Manifestosu'na dayanır: çalışan yazılımı kapsamlı belgelerden, müşteriyle iş birliğini sözleşme pazarlığından, değişikliğe uyumu planı körü körüne izlemekten daha değerli sayar. Bu, planın ve belgenin gereksiz olduğu anlamına gelmez; önceliğin nereye verildiğini söyler.
Gerçek hayatta çoğu proje saf bir modelle yürümez. Kapsamı ve bütçeyi baştan şelale mantığıyla çerçeveleyip geliştirmeyi çevik döngülerle ilerleten hibrit yapı, özellikle sabit bütçe ve sabit teslim tarihi isteyen kurumsal projelerde en yaygın seçimdir.
Scrum Nasıl Çalışır?
Scrum, işi sprint adı verilen kısa ve sabit süreli döngülere bölen çevik bir çerçevedir. Her sprintin sonunda kullanılabilir, test edilmiş bir yazılım parçası ortaya çıkar. Scrum Kılavuzu'na göre sprint en fazla bir ay sürer; çoğu ekip iki haftalık sprintle çalışır.
- Roller: Ürün sahibi neyin, hangi sırayla yapılacağına karar verir (iş tarafını temsil eder). Scrum yöneticisi sürecin işlemesini ve engellerin kalkmasını sağlar. Geliştirme ekibi işi tasarlar, kodlar ve test eder.
- Ürün biriktirme listesi (product backlog): Yapılacak tüm işlerin öncelik sırasına göre dizildiği liste. Üst sıradakiler ayrıntılı, alttakiler kabadır. Kullanıcı hikâyeleri burada yaşar.
- Sprint planlaması: Ekip, biriktirme listesinin başından o sprintte tamamlayabileceği kadar işi seçer.
- Günlük toplantı: En fazla 15 dakikalık, ayakta yapılan senkronizasyon: dün ne yaptım, bugün ne yapacağım, beni ne engelliyor?
- Sprint gözden geçirmesi: Çalışan yazılım ürün sahibine ve paydaşlara gösterilir; geri bildirim biriktirme listesine döner.
- Retrospektif: Ekip kendi çalışma biçimini konuşur: neyi iyi yaptık, neyi değiştireceğiz?
Scrum'ın gücü, bilgiyi erken getirmesidir. Müşteri yazılımı iki haftada bir görür; yanlış anlaşılma iki haftada yakalanır, iki ayda değil.
Sprint Hızına Bakarak Teslim Tarihi Nasıl Tahmin Edilir?
Çevik projelerde teslim tarihi, ekibin geçmiş sprintlerde ne kadar iş bitirdiğine bakılarak tahmin edilir. Bu orana ekip hızı (velocity) denir ve sprint başına tamamlanan iş miktarının (çoğunlukla hikâye puanının) ortalamasıdır. Formül basittir: Gereken sprint sayısı = Kalan iş ÷ Ekip hızı.
Örnek (rakamlar temsilidir): Bir ekibin son üç sprintte tamamladığı iş sırasıyla 21, 24 ve 27 puandır; ortalama hız (21 + 24 + 27) ÷ 3 = 24 puandır. Ürün biriktirme listesinde kalan iş 120 puandır. Gereken sprint sayısı 120 ÷ 24 = 5'tir. Sprintler iki haftalıksa tahmini teslim 10 haftadır.
Tahmini tek rakam yerine aralık olarak vermek daha dürüsttür. En düşük hızla (21) hesaplarsanız 120 ÷ 21 ≈ 5,7, yani 6 sprint (12 hafta) çıkar; en yüksek hızla (27) 120 ÷ 27 ≈ 4,4, yani 5 sprint (10 hafta). Doğru cümle "10 ile 12 hafta arası" olur. Her sprintte yeni bilgi geldiğinden tahmin de güncellenir; kalan iş her sprintte yeniden hesaplanır ve ürün sahibiyle paylaşılır.
Sürekli Entegrasyon ve Sürekli Teslim (CI/CD) Nedir?
Sürekli entegrasyon (CI), geliştiricilerin yazdığı kodun sık sık ortak depoda birleştirilmesi ve her birleştirmede otomatik derleme ve testlerin çalıştırılmasıdır. Sürekli teslim (CD) ise testten geçen sürümün otomatik olarak yayına hazırlanması, çoğu zaman tek tuşla ya da otomatik canlıya alınmasıdır. Birlikte CI/CD denir.
Bunun işletme açısından faydası şudur: Yayın korkulan, nadir ve uzun bir olay olmaktan çıkar; küçük, sık ve geri alınabilir bir rutin olur. Bir hata çıktığında hangi değişikliğin neden olduğu kolayca bulunur ve önceki sürüme dönülür. CI/CD'nin yaygın parçaları şunlardır:
- Sürüm kontrolü: Kodun tüm geçmişi tutulur; kim, neyi, ne zaman değiştirdi bellidir (çoğunlukla Git).
- Otomatik test: Her değişiklikte birim ve entegrasyon testleri çalışır; kırılan şey hemen görülür.
- Ayrı ortamlar: Geliştirme, test ve canlı ortam birbirinden ayrıdır; gerçek müşteri verisi test ortamına taşınmaz.
- Geri dönüş planı: Yayında sorun çıkarsa bir önceki çalışan sürüme hızla dönülebilir.
- İzleme: Yayından sonra hata ve performans izlenir; sorun müşteri şikâyet etmeden fark edilir.
Hangi Proje İçin Hangi Model Uygundur?
Model seçimini üç soru belirler: Gereksinim ne kadar net ve sabit? Müşteri sürece ne kadar katılabilir? Değişiklik ne kadar beklenir? Gereksinim netse ve değişmeyecekse şelale ya da hibrit; gereksinim zamanla netleşecekse ve geri bildirim değerliyse çevik; sık yayın gereken canlı ürünlerde sürekli teslim öne çıkar.
| Durum | Uygun yaklaşım | Neden? |
|---|---|---|
| Yasal ya da sözleşmeyle sabit kapsam, değişiklik beklenmiyor | Şelale ya da hibrit | Kapsam ve teslim baştan bağlayıcıdır |
| Yeni bir ürün, kullanıcı ihtiyacı tam bilinmiyor | Çevik (Scrum) | Her sprintte öğrenilir, yön düzeltilir |
| Kurum içi sistem, süreç net ama çok modüllü | Hibrit: baştan çerçeve, parça parça teslim | Bütçe öngörülebilir, risk erken görülür |
| Canlıda çalışan, sürekli gelişen web ürünü | Kanban ve CI/CD | Küçük işler akar, yayın rutindir |
| Küçük, kısa bir iş (birkaç hafta) | Hafif çevik: kısa analiz, haftalık gösterim | Ağır süreç işten büyük olur |
Okumanızı öneririz: Hazır yazılım mı, özel yazılım mı? Karar rehberi
Yazılım Geliştirme Sürecinde Sık Yapılan Hatalar Nelerdir?
En sık yapılan hatalar; analizi atlayıp doğrudan koda başlamak, müşteriyi süreçten uzak tutmak, testi sona bırakmak, modeli ismine göre seçip projenin gerçeğine bakmamak ve bakım aşamasını bütçeye katmamaktır.
- Analizi atlamak: "Hızlı başlayalım" diye kısaltılan analiz, projenin ortasında pahalı bir yeniden yazıma dönüşür.
- Müşteri katılımının eksikliği: Çevik çalışmak, müşterinin her sprintte karar verebilecek biriyle sürece katılmasını gerektirir. Cevap vermeyen ürün sahibi, en iyi sürecin bile işlemesini engeller.
- Testi sona bırakmak: Hata ne kadar geç bulunursa o kadar pahalı düzelir. Test her aşamanın ve her sprintin parçası olmalıdır.
- "Çevik" adı altında plansızlık: Çevik, plansız çalışmak demek değildir; kısa vadeli planı sık güncellemek demektir. Biriktirme listesi, öncelik ve kabul kriteri yine gereklidir.
- Kapsamı kontrolsüz genişletmek: Her yeni istek bir iş kalemidir; kapsam, süre ve bütçeye etkisi konuşulmadan eklenmemelidir.
- Bakımı unutmak: Yazılım yayına alındığında bitmez. Güvenlik güncellemeleri, yedekleme, izleme ve yeni sürümler için bütçe ve sorumlu baştan belirlenmelidir.
Okumanızı öneririz: Veri yedekleme nasıl yapılır? RPO, RTO ve 3-2-1 kuralı
Yazılım Geliştirme Sürecine Siz Nasıl Katkı Verirsiniz?
Yazılım yaptıran taraf sürecin seyircisi değil, ortağıdır. Kararlar hızlı verilir, içerik ve veri zamanında hazırlanır, her gösterimde geri bildirim net ve tek kaynaktan gelirse proje hızlanır. Bunun için beş alışkanlık yeterlidir:
- Tek bir karar verici belirleyin: Öncelik kimin sözüyle belirleniyor, baştan bilinsin.
- Kullanıcıyı sürece katın: Yazılımı kullanacak kişiler gösterimlere gelsin; yönetici özeti kullanıcının sahadaki gerçeğinin yerini tutmaz.
- Geri bildirimi yazılı ve somut verin: "Beğenmedim" yerine "şu ekranda şu bilgi eksik" yazın.
- Hazırlıkları aksatmayın: Metinler, ürün verisi, hesap bilgileri ve entegrasyon erişimleri gecikirse yazılım hazır olsa bile yayın gecikir.
- Kabul kriterini önceden konuşun: "Bitti" tanımı baştan yazılıysa teslimlerde tartışma çıkmaz.
Okumanızı öneririz: Özel Yazılım Nedir? Türleri, Örnekleri, Avantajları ve Hangi İşletmeler İçin Doğru?
Okumanızı öneririz: Yazılım Bakım ve Destek Sözleşmesi (SLA) Nedir? Kapsam, Süreler ve Ücret Rehberi
Okumanızı öneririz: Mikroservis mimarisi nedir? Monolit farkı, maliyet ve karar rehberi
Okumanızı öneririz: Teknik Borç Nedir?
İnovabil ile Yazılım Geliştirme Süreci
İnovabil olarak her projede aynı yolu izliyoruz: analiz, tasarım, geliştirme, test, yayın, bakım ve destek. Analizde işinizi ve kullanıcılarınızı dinleyip kapsamı, iş kalemlerini ve takvimi yazılı teklife dönüştürüyoruz. Tasarımda ekran akışlarını ve tıklanabilir prototipi kod yazılmadan önce sizinle denetliyoruz. Geliştirmeyi parçalı (sprint) ilerletiyor, düzenli demo toplantılarında çalışan sürümü gösteriyor, kod incelemesi ve otomatik testlerle destekliyoruz; böylece ilk çalışan sürümü proje bitmeden görmeye başlıyorsunuz. Test, yayın ve yayın sonrası güncelleme ve destekle yanınızda kalıyoruz.
Süreç adımlarımızı süreç sayfamızda, yaptığımız işleri referanslar sayfamızda bulabilirsiniz. Projenizin kapsamını, kimlerin kullanacağını ve beklediğiniz takvimi birkaç cümleyle anlatın; size uygun süreç modelini birlikte belirleyelim.
Sık Sorulan Sorular
Yazılım geliştirme süreci (SDLC) nedir, kısaca nasıl tanımlanır?
Yazılım geliştirme süreci, bir yazılımın planlamadan canlıya ve bakıma kadar hangi aşamalardan geçeceğini, her aşamada neyin üretileceğini ve kimin sorumlu olduğunu tanımlayan çalışma düzenidir. Aşamalar genellikle planlama, analiz, tasarım, geliştirme, test, yayın ve bakımdır.
Çevik model mi, şelale modeli mi daha iyidir?
Biri diğerinden mutlak üstün değildir; projenin yapısına bağlıdır. Gereksinim net ve sabitse şelale ya da hibrit, gereksinim zamanla netleşiyorsa ve geri bildirim değerliyse çevik daha uygundur. Birçok kurumsal proje, baştan çerçeve çizip geliştirmeyi çevik döngülerle yürüten hibrit bir yapı kullanır.
Scrum nedir, sprint ne kadar sürmelidir?
Scrum, işi sprint adı verilen kısa ve sabit süreli döngülere bölen çevik bir çerçevedir. Scrum Kılavuzu'na göre sprint en fazla bir ay sürer; çoğu ekip iki haftalık sprint kullanır. Her sprintin sonunda çalışan, test edilmiş bir yazılım parçası ortaya çıkar.
Çevik projede teslim tarihi nasıl belirlenir?
Ekibin geçmiş sprintlerdeki ortalama hızı (sprint başına tamamlanan puan) ölçülür; kalan iş bu hıza bölünerek gereken sprint sayısı bulunur. Tahmin tek rakam yerine aralık olarak verilir ve her sprintte güncellenir. Örneğin 120 puanlık iş, 24 puanlık hızla 5 sprint, yani iki haftalık sprintlerde yaklaşık 10 hafta sürer.
CI/CD yazılım geliştirmeye ne kazandırır?
Sürekli entegrasyon ve teslim, kodun sık sık birleştirilip otomatik test edilmesini ve testten geçen sürümün güvenle yayına alınmasını sağlar. Yayın nadir ve riskli bir olay olmaktan çıkar; küçük, sık ve geri alınabilir bir rutin olur. Hata bulmak ve düzeltmek de hızlanır.