Yazılım Geliştirme Nedir?
Kısa tanım
Yazılım geliştirme, bir ihtiyacı çalışan ve bakımı yapılabilen bir yazılıma dönüştürme sürecidir. Yalnızca kod yazmayı değil; gereksinim analizini, tasarımı, test etmeyi, canlıya almayı ve yayından sonraki bakım ile iyileştirmeyi de kapsar. Bu aşamalar şelale gibi sıralı ya da Agile gibi kısa ve tekrarlayan döngülerle yürütülebilir. Süreçte analist, tasarımcı, geliştirici, test ve operasyon gibi farklı roller birlikte çalışır.
Diğer adları: software development, yazılım geliştirme süreci, SDLC, yazılım geliştirme yaşam döngüsü
Kod yazmak işin yalnızca bir parçası
Dışarıdan bakıldığında yazılım geliştirme klavye başında geçen saatler gibi görünür. Oysa bir projenin başarısını çoğu zaman kodun kendisinden çok, neyin neden yapıldığının doğru anlaşılması belirler. Yanlış anlaşılmış bir ihtiyaç kusursuz kodla çözülse bile ortaya kimsenin kullanmadığı bir ürün çıkar. Bu yüzden süreç, “ne yazacağız?” sorusundan çok önce “hangi sorunu çözüyoruz ve başarıyı nasıl anlayacağız?” sorusuyla başlar.
Yaşam döngüsünün aşamaları
- Keşif ve gereksinim analizi: Kullanıcılar, iş kuralları, entegrasyonlar ve kısıtlar belirlenir. Çıktısı; kullanıcı hikâyeleri, kabul kriterleri ve önceliklendirilmiş bir iş listesidir.
- Tasarım: Ekran akışları ve arayüz tasarımı ile birlikte veri modeli, servisler arası iletişim ve altyapı kararları verilir.
- Geliştirme: Kod küçük, gözden geçirilebilir parçalar hâlinde yazılır ve Git gibi bir sürüm kontrol sisteminde tutulur.
- Test: Birim testleri, entegrasyon testleri ve kullanıcı kabul testleri hataları canlıya çıkmadan yakalar.
- Yayına alma: Değişiklik önce bir staging ortamında denenir, ardından üretim ortamına taşınır.
- Bakım ve gelişim: Güvenlik güncellemeleri, hata düzeltmeleri, performans iyileştirmeleri ve yeni ihtiyaçlar. Bir yazılımın ömrünün büyük bölümü bu aşamada geçer.
Şelale, Agile ve pratikteki karışım
Şelale (waterfall) yaklaşımında her aşama bir öncekinin tamamlanmasını bekler; kapsam baştan sabitlenir. Gereksinimlerin gerçekten değişmediği, örneğin mevzuatla tanımlanmış süreçlerde işe yarar; ancak hatalı bir varsayım çoğu zaman proje sonunda, düzeltmesi en pahalı anda ortaya çıkar.
2001'de yayımlanan Agile Manifestosu farklı bir öncelik sırası önerdi: süreç ve araçlardan çok bireyler ve etkileşimler, kapsamlı dokümantasyondan çok çalışan yazılım, sözleşme pazarlığından çok müşteriyle iş birliği, plana bağlı kalmaktan çok değişime yanıt vermek. Scrum, iki ila dört haftalık sprintlerle; Kanban ise iş akışını görselleştirip aynı anda yürüyen iş sayısını sınırlayarak bu fikri uygular. Gerçek projelerin çoğu bir karışımdır: bütçe ve ana kapsam baştan belirlenir, ayrıntılar kısa döngülerle netleşir. Bu döngülerin ilk hedefi genellikle bir MVP'dir.
Ekipte kim ne yapar?
| Rol | Sorumluluk |
|---|---|
| Ürün sahibi / iş analisti | İhtiyacı tanımlar, önceliklendirir, “bitti” kriterini belirler |
| UX/UI tasarımcı | Akışları ve arayüzü kullanıcının bakış açısından kurgular |
| Frontend ve backend geliştirici | Arayüzü, iş mantığını, veritabanını ve entegrasyonları kodlar |
| Test / QA | Test senaryolarını yazar, otomasyonu kurar, kaliteyi raporlar |
| DevOps / operasyon | Altyapıyı, dağıtım hattını, izleme ve yedeklemeyi yönetir |
Küçük ekiplerde bu rollerin birkaçı aynı kişide toplanır; önemli olan rolün kendisinin unutulmamasıdır. Testten sorumlu kimse yoksa testi sonunda kullanıcı yapar.
Kaliteyi belirleyen alışkanlıklar
- Kod incelemesi: Her değişikliği en az bir başka geliştiricinin okuması hataları ve bilgi tekelini azaltır.
- Otomatik test ve dağıtım: CI/CD hattı her değişiklikte testleri çalıştırır ve yayına almayı tekrarlanabilir hâle getirir.
- Borcu görünür tutmak: Zaman baskısıyla alınan kısa yollar teknik borç olarak kaydedilir ve düzenli olarak geri ödenir.
- Belgelemek: Kurulum adımları, mimari kararlar ve ortam değişkenleri yazılı olmalıdır; projeyi bilen tek kişinin ayrılması bir projeyi durdurmamalıdır.