- 17 Nis 2015
- 1,649
- 1,576
- 25
Yazılım Geliştirme Yaşam Döngüsü
Yazılım Geliştirme Yaşam Döngüsü (SDLC), yüksek kaliteli yazılım oluşturmak için açıkça tanımlanmış
süreçlere sahip bir metodolojiyi ifade eder. Ayrıntılı olarak, SDLC metodolojisi, yazılım geliştirmenin
aşağıdaki aşamalarına odaklanır:
İhtiyaç analizi
Planlama
Mimari tasarım gibi yazılım tasarımı
Yazılım geliştirme
Test yapmak
Dağıtım
Yazılım geliştirme yaşam döngüsü nedir?
SDLC veya Yazılım Geliştirme Yaşam Döngüsü, mümkün olan en kısa sürede en yüksek kalitede ve en
düşük maliyetle yazılım üreten bir süreçtir. SDLC, bir kuruluşun iyi test edilmiş ve üretimde kullanıma
hazır yüksek kaliteli yazılımı hızlı bir şekilde üretmesine yardımcı olan iyi yapılandırılmış bir aşama
akışı sağlar.
SDLC, girişte açıklandığı gibi altı aşamadan oluşur. Popüler SDLC modelleri arasında şelale modeli,
spiral model ve Çevik model bulunur.
SDLC Nasıl Çalışır?
SDLC, yazılım geliştirme maliyetini düşürürken aynı zamanda kaliteyi artırarak ve üretim süresini
kısaltarak çalışır. SDLC, yazılım geliştirme projelerinin tipik tuzaklarını ortadan kaldıran bir planı
izleyerek bu görünüşte farklı hedeflere ulaşır. Bu plan, eksiklikler için mevcut sistemleri
değerlendirerek başlar.
Daha sonra, yeni sistemin gereksinimlerini tanımlar. Daha sonra yazılımı analiz, planlama, tasarım,
geliştirme, test etme ve devreye alma aşamalarında oluşturur. Son kullanıcı veya müşteriden geri
bildirim istememek gibi maliyetli hataları tahmin ederek, SLDC gereksiz yeniden çalışmayı ve
sonradan yapılan düzeltmeleri ortadan kaldırabilir.
Test aşamasına güçlü bir odaklanma olduğunu bilmek de önemlidir. SDLC tekrarlayan bir metodoloji
olduğundan, her döngüde kod kalitesini sağlamanız gerekir. Pek çok kuruluş, test etmek için az çaba
sarf etme eğilimindeyken, teste daha güçlü bir odaklanma onlara çok fazla yeniden çalışma, zaman ve
para tasarrufu sağlayabilir bu yüzden doğru test türlerini yazın.
Aşamalar
SDLC'nin en iyi uygulamalarını ve / veya aşamalarını takip etmek, sürecin sorunsuz, verimli ve üretken
bir şekilde işlemesini sağlar.
1. Mevcut Sorunları Belirlemek
Müşteriler, satış personelleri, uzman personeller ve
programcılar dahil olmak üzere tüm paydaşlardan girdi almak anlamına gelir. Hedef olarak iyileştirme
ile mevcut sistemin güçlü ve zayıf yönlerini öğrenin.
2. Planlama
Bu durumda takım, tespit edilen gereksinimleri uygulamak için gereken
maliyeti ve kaynakları belirler. Ayrıca, ilgili riskleri detaylandırır ve bu riskleri yumuşatmak için alt
planlar sağlar. Diğer bir deyişle, ekip projenin fizibilitesini ve en düşük risk göz önünde
bulundurularak projeyi nasıl başarılı bir şekilde uygulayabileceğini belirlemelidir.
3. Tasarım
Bu kısımda, Tasarım Özellikleri adı verilen bir tasarım planına dönüştürerek başlar.
Tüm paydaşlar daha sonra bu planı gözden geçirir ve geri bildirim ve öneriler sunar.
Paydaş girdilerini toplamak ve bu belgeye dahil etmek için bir plana
sahip olmak çok önemlidir. Bu aşamadaki başarısızlık, neredeyse kesinlikle, en iyi ihtimalle maliyet
aşımlarına ve en kötü ihtimalle projenin tamamen çökmesine neden olacaktır.
4. Yapı
Bu aşamada asıl gelişme başlar. Her geliştiricinin üzerinde anlaşmaya varılan plana uyması önemlidir.
Ayrıca, kod stili ve uygulamaları hakkında uygun yönergelere sahip olduğunuzdan emin olun.
Örneğin, dosyalar için bir isimlendirme tanımlayın veya camelCase gibi bir değişken adlandırma stili
tanımlayın. Bu, ekibinizin anlaşılması daha kolay, aynı zamanda bir sonraki aşamada test etmesi için
organize ve tutarlı bir kod üretmesine yardımcı olacaktır.
5. Kod Testi
Bu aşamada kusurları ve eksiklikleri test ediyoruz. Ürün orijinal teknik
özellikleri karşılayana kadar bu sorunları düzeltiriz. Kısaca, kodun tanımlanan gereksinimleri karşılayıp
karşılamadığını doğrulamak istiyoruz.
6. Yazılım Dağıtımı
Bu aşamada amaç, kullanıcıların ürünü kullanmaya başlayabilmesi için yazılımı üretim ortamına
dağıtmaktır. Ancak birçok kuruluş, ürünü test veya hazırlık ortamı gibi farklı dağıtım ortamlarında
taşımayı tercih eder. Bu, herhangi bir paydaşın ürünü piyasaya sürmeden önce ürünle güvenli bir
şekilde oynamasına izin verir. Ayrıca, bu, ürünü piyasaya sürmeden önce herhangi bir son hatanın
yakalanmasını sağlar.
Ekstra: Yazılım Bakımı
Plan gerçekleştirildiğin de neredeyse hiçbir zaman mükemmel olmaz. Dahası, gerçek dünyadaki
koşullar değiştikçe, yazılımı eşleşecek şekilde güncellememiz ve ilerletmemiz gerekiyor.
DevOps hareketi, SDLC'yi bazı şekillerde değiştirdi. Geliştiriciler artık tüm geliştirme sürecinin giderek
daha fazla adımından sorumludur. Ayrıca sola kaymanın değerini de görüyoruz. Geliştirme ve Ops
ekipleri, performansı izlemek ve bir uygulamanın başlangıcından kullanımdan kaldırılmasına kadar
olan hataları tespit etmek için aynı araç setini kullandığında, bu ortak bir dil ve ekipler arasında daha
hızlı devir sağlar.
Uygulama performansı izleme araçları bir geliştirme, kalite güvence ve üretim ortamında
kullanılabilir. Bu, geliştirme yaşam döngüsü boyunca herkesin aynı araç setini kullanmasını sağlar.
Yazılım Geliştirme Süreç Modelleri
Şelale Modeli
Bu SDLC modeli, en eski ve en basit olanıdır. Bu metodoloji ile bir aşamayı bitirip bir sonrakine
başlıyoruz. Her aşamanın kendi mini planı ve her aşama bir sonrakine "şelaleleri" vardır. Bu modelin
en büyük dezavantajı, eksik bırakılan küçük detayların tüm süreci durdurabilmesidir.
Çevik Model
Çevik SDLC modeli, ürünü döngülere ayırır ve çok hızlı bir şekilde çalışan bir ürün sunar. Bu
metodoloji bir dizi yayın üretir. Her bir sürümün test edilmesi, sonraki sürüme dahil edilen bilgileri
geri besler. Robert Half'e göre bu modelin dezavantajı, müşteri etkileşimine yapılan yoğun vurgunun
bazı durumlarda projeyi yanlış yöne yönlendirebilmesidir.
Yinelemeli Model
Bu SDLC modeli tekrarı vurgular. Geliştiriciler, çok hızlı bir şekilde ve nispeten düşük bir maliyetle bir
sürüm oluşturur, ardından hızlı ve birbirini takip eden sürümlerle onu test eder ve iyileştirir. Buradaki
büyük bir dezavantaj, kontrol edilmediği takdirde kaynakları hızla tüketebilmesidir.
V Şeklinde Model
Şelale modelinin bir uzantısı olan bu SDLC metodolojisi, geliştirmenin her aşamasında test eder.
Şelalede olduğu gibi, bu süreç de engellerle karşılaşabilir.
Büyük Patlama Modeli
Bu yüksek riskli SDLC modeli, kaynaklarının çoğunu geliştirmeye harcıyor ve küçük projeler için en iyi
sonucu veriyor. Diğer yöntemlerin kapsamlı gereksinimleri tanımlama aşamasından yoksundur.
Spiral Modeli
SDLC modellerinin en esnek olanı olan spiral model, tekrarlama vurgusu açısından yinelemeli modele
benzer. Spiral model, her geçişte kademeli iyileştirmelerle planlama, tasarım, inşa ve test
aşamalarından defalarca geçer.
Not;
Konuyu hazırlamamda yardımcı olan, boole dostuma, çok teşekkür ederim.
Son düzenleme:
