Yazılım Geliştirme Yaşam Döngüsü

Yazılım geliştirme yalnızca kod yazmaktan ibaret değildir. Kodlama sürecin yaklaşık %15-20'sidir; geri kalanı problemi doğru anlamak, kaliteyi denetlemek ve sürdürülebilirliği sağlamaktır. Bu süreci yöneten disipline Yazılım Geliştirme Yaşam Döngüsü (SDLC) denir.

SDLC nedir?

SDLC, bir yazılım projesini fikir aşamasından kullanımdan kaldırılmasına kadar yöneten yapısal bir yöntemdir. Buzdağı benzetmesinde kodlama ve arayüzler suyun üstünde görünen kısım, müşteri görüşmeleri, fizibilite, veri tabanı tasarımı, risk analizi ve test senaryoları ise suyun altındaki büyük kütledir.

SDLC'nin amaçları disiplin (plansız çalışmayı önlemek), kontrol (bütçe ve zaman sınırlarına uymak), kalite ve öngörülebilirliktir. Amaç, tek kişinin yazdığı dokümansız bir "program"dan; test edilmiş, dokümante edilmiş ve müşteri gereksinimine göre üretilmiş bir yazılım ürününe geçmektir.

Altı evre

1. Planlama: Fizibilite değerlendirilir; bütçe, kaynak ve zaman planı yapılır. Temel soru: Bu projeyi yapmaya değer mi?
2. Analiz: Müşterinin ne istediği ayrıntılı anlaşılır. Çıktısı Gereksinim Spesifikasyon Dokümanı'dır (SRS).
3. Tasarım: Teknik mimari, veri tabanı şemaları ve kullanıcı arayüzleri tasarlanır.
4. Gerçekleştirme: Tasarım koda dökülür, altyapı kurulur.
5. Test: Hatalar (bug) bulunur ve gereksinimlerin karşılanıp karşılanmadığı kontrol edilir.
6. Bakım: Teslimden sonraki güncellemeler ve düzeltmelerdir. En uzun süren ve en maliyetli evredir.

SDLC modelleri

• Şelale (Waterfall): Her aşama bir öncekinin bitmesiyle başlar, geri dönüş çok zordur. Yönetimi basit, dokümantasyonu güçlüdür; ancak değişime kapalıdır ve müşteri ürünü yalnızca en sonda görür. Gereksinimleri değişmeyecek projelere uygundur.
• V-Modeli: Şelalenin test odaklı hâlidir; her geliştirme adımının karşısında bir test adımı bulunur. Hata tespiti erken başlar. Tıbbi cihaz ve havacılık gibi kritik sistemlerde kullanılır.
• Spiral model: Proje, her birinde risk analizi yapılıp prototip üretilen döngülerle ilerler. Risk yönetimi mükemmeldir ama karmaşık ve maliyetlidir; küçük projelere uygun değildir.
• Çevik (Agile): Proje 2-4 haftalık sprintlere bölünür, her sprint sonunda çalışan bir parça teslim edilir. Değişime hızlı uyum sağlar ve müşteri sürekli sürece katılır; dokümantasyonu zayıf kalabilir. En yaygın uygulaması Scrum'dır. Mobil ve web projelerine uygundur.

En iyi model yoktur, projeye en uygun model vardır. Sıfır hata gereken bir nükleer santral yazılımında V-Modeli, hızla değişen bir e-ticaret sitesinde Çevik model, gereksinimleri baştan belli bir arşiv sisteminde Şelale yeterli olabilir.

Vaka: güvenlik kritik bir tıbbi cihaz

Vücuda yerleştirilen, sıfır hata toleranslı, teknolojisi henüz belirsiz ve ağır regülasyona tabi bir cihaz yazılımında en uygun yaklaşım V-Modeli ile Spiral modelin birleştirildiği hibrit modeldir. V-Modeli izlenebilirliği ve doğrulamayı, Spiral ise belirsizlik ve risk yönetimini sağlar. Şelale değişime kapalı olduğu için, Çevik ise hafif dokümantasyonu izlenebilirlik zorunluluğuyla çeliştiği ve "hızlı hata yap" mantığı hasta üzerinde denenemeyeceği için elenir.

Use case (kullanım durumu)

Use case, sistemin bir işi nasıl yaptığına değil, ne yaptığına odaklanan bir senaryodur. Bileşenleri şunlardır:

• Aktör: Sistemi kullanan kişi ya da başka bir sistem.
• Amaç: Aktörün ulaşmak istediği hedef.
• Ön koşul: Senaryonun başlaması için gereken şart. Örnek: ürün stokta olmalı.
• Ana senaryo: Her şeyin yolunda gittiği akış.
• Alternatif senaryo: İstisna ve hata durumları. Örnek: stok yoksa uyarı verilir.

Use case diyagramları PlantUML, draw.io ve Mermaid gibi araçlarla çizilebilir.