Yazılım Geliştirme

Yazılım Geliştirme Süreci: Fikirden Yayına 7 Aşama

14.07.2026 · 3 dk okuma · 1 okunma

Yazılım Geliştirme Süreci: Fikirden Yayına 7 Aşama

Yazılım geliştirme süreci, bir cümlelik fikrin binlerce satırlık çalışan bir ürüne dönüşme yolculuğudur. Bu yolculuğun uzunluğunu yazılan kod miktarı değil, verilen kararların netliği belirler. Aşağıda; keşiften bakıma kadar yedi aşamayı, her birinin somut çıktısıyla ve sahada en sık düşülen tuzaklarıyla birlikte ele alıyoruz.

Yazılım geliştirme sürecinin yedi aşamasını özetleyen şema
Yedi aşama; küçük projelerde günlere, kurumsal projelerde aylara yayılır ama sırası değişmez.

1. Keşif: Doğru problemi bulmak

Projelerin çoğu yanlış kodlandığı için değil, yanlış problemi çözdüğü için başarısız olur. Keşif aşamasının tek amacı şu üç soruyu cevaplamaktır: Bu sorunu kim yaşıyor? Bugün nasıl idare ediyor? Çözülürse ölçülebilir olarak ne değişir?

"Personel takip sistemi istiyoruz" cümlesi bir gereksinim değildir. Altını kazıdığınızda genellikle "ay sonunda fazla mesai hesabı elle yapılıyor ve iki gün sürüyor" gibi ölçülebilir bir acı çıkar. Ölçülebilir acı, projenin başarı kriterine dönüşür.

2. Analiz: Kabul kriterlerini yazıya dökmek

Analiz, hayalleri cümlelere çevirme işidir. Her istek için "hangi durumda tamamlanmış sayılır" sorusunun cevabı yazılmalıdır. Örnek: "Yıllık izin talebi oluşturulduğunda amirin ekranında bekleyen talep olarak görünür; amir onaylayınca takvime işlenir ve kalan izin bakiyesi düşer."

Bu tek cümle, üç ekran, iki yetki kontrolü ve bir bakiye hesabı demektir. Kabul kriteri yazılmadan başlanan işlerde "bu böyle olacaktı sanıyordum" tartışması kaçınılmazdır.

Sık yapılan hata: istisnaları sonraya bırakmak

Ana akış herkesin aklında aynıdır; asıl fark istisnalarda çıkar. İzin talebi yıl sınırını aşarsa, personel talep sonrası işten ayrılırsa, amir onaylamadan izin günü gelirse ne olacak? İstisnalar analizde konuşulmazsa, yayından sonra veri düzeltme betiği olarak geri döner.

3. Tasarım: Veri modeli ekranlardan önce gelir

Deneyimli ekipler önce veriyi, sonra ekranı tasarlar. Çünkü ekran bir haftada değişir, kötü kurgulanmış bir veri modeli yıllarca taşınır. Bu aşamada tabloların ilişkileri, hangi alanın zorunlu olduğu, hangi kaydın silinip silinemeyeceği kararlaştırılır.

Pratik bir kural: bir tabloda "durum" alanı varsa, o durumlar arasındaki geçişleri de yazın. Taslak → incelemede → yayında geçişi serbestken, arşivden taslağa dönüş yasaksa bu kural veri modeliyle birlikte doğar.

4. Geliştirme: Küçük parçalar, sık birleştirme

Üç haftalık bir dalı (branch) tek seferde birleştirmek, üç haftalık riski tek seferde almaktır. Bunun yerine iş, yarım gün ile iki gün arasında tamamlanabilecek parçalara bölünür ve her parça ana dala hızlıca katılır.

  • Her parça tek başına anlamlı olmalı ("izin talebi formu", "izin bakiyesi hesabı" gibi).
  • Yarım kalan işler bayrak (feature flag) arkasında saklanabilir.
  • Kod incelemesi (code review) parçalar küçükken işe yarar; 2.000 satırlık bir incelemeyi kimse gerçekten okumaz.

5. Test: Güvenin kaynağı

Test yazmak, yavaşlatan bir ek iş değil, değişiklik yapabilme cesaretidir. Testi olmayan bir modülde altı ay sonra kimse bir satır dokunmak istemez. En azından şu üç katman hedeflenmelidir: hesaplama mantığı için birim testleri, kayıt akışı için entegrasyon testleri, kritik ekranlar için uçtan uca senaryolar.

Kural: Üretimde bir hata çıktıysa, düzeltmeden önce o hatayı yakalayan testi yazın. Böylece aynı hata iki kez yaşanmaz.

6. Yayın: Geri dönüşü olan adımlar

İyi bir yayın planı, "nasıl çıkacağız" kadar "nasıl geri alacağız" sorusunu da cevaplar. Veritabanı değişiklikleri göç (migration) dosyalarıyla sürümlenir, yayın öncesi yedek alınır, yayın saatinde kullanıcının en az olduğu zaman dilimi seçilir.

Yayın kontrol listesi kısa olmalı ama her seferinde uygulanmalıdır: yedek alındı mı, göçler çalıştı mı, hata kayıtları temiz mi, kritik üç akış elle denendi mi?

7. Bakım: Asıl maliyetin oluştuğu yer

Bir yazılımın ömür boyu maliyetinin büyük bölümü ilk yazımda değil, sonraki yıllarda oluşur. Bu yüzden izleme (hata kayıtları, yavaş sorgu takibi), düzenli bağımlılık güncellemeleri ve teknik borcun görünür tutulması sürecin parçasıdır.

Sürecin uluslararası kabul görmüş bir çerçevesini incelemek isterseniz OWASP SAMM belgeleri, güvenlik boyutunu da içeren olgunluk seviyeleri sunar.

Toparlarsak

Yedi aşamanın hiçbiri atlanamaz; yalnızca ölçeği değişir. Bir haftalık işte keşif yarım saat, analiz bir sayfa, tasarım bir çizim olabilir. Önemli olan sıranın korunmasıdır: önce problem, sonra kural, sonra veri, en sonda kod. Tersine çevrildiğinde ortaya çıkan şey yazılım değil, sürekli yamanan bir yığındır.

Paylaş:

Sık Sorulan Sorular

Kapsamı net, tek ekranlı bir araç birkaç günde çıkabilir; çok kullanıcılı kurumsal bir modül 2-4 ay sürer. Süreyi belirleyen kod miktarı değil, karar sayısıdır: ne kadar çok belirsiz kural varsa süre o kadar uzar.

Gereksinimler mevzuatla sabitlenmişse (bordro, vergi, resmî raporlama) şelaleye yakın çalışmak güvenlidir. Kullanıcı davranışına göre şekillenecek ürünlerde iki haftalık döngülerle ilerleyen çevik yaklaşım daha az israf üretir.

Analizde bir saatte değiştirilebilen bir kural, geliştirme aşamasında bir güne, yayından sonra veri düzeltmesiyle birlikte bir haftaya mal olur. Maliyet, hatanın fark edildiği aşama ilerledikçe katlanarak artar.

Tek sayfalık bir gereksinim notu, bir veri modeli çizimi, görev listesi, sürüm kontrolü ve yayın öncesi kontrol listesi. Bu beşi olmadan hiçbir proje büyümeyi kaldıramaz.