Yazılım Yaşam Döngüsü Modelleri: Her Üründe Olduğu Gibi Yazılımların Da Bir Yaşam Döngüsü Var Mıdır?
top of page
Ara

Yazılım Yaşam Döngüsü Modelleri: Her Üründe Olduğu Gibi Yazılımların Da Bir Yaşam Döngüsü Var Mıdır?

Güncelleme tarihi: 12 May 2022




Her bilgisayar mühendisi adayının bir noktada karşısına çıkan “yazılım yaşam döngüsü modelleri” bazen anlaması zor bir konsept olabilir. Her ürün gibi yazılımların da bir yaşam döngüsü vardır fakat yazılım yaşam döngüleri diğer ürünlerden farklı olarak sürekli güncellenmesi ve değişmesi gerektiği için biraz daha uğraştırıcı bir süreçtir.


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

Genel olarak yazılım yaşam döngüsü 5 adımdan oluşur. Bu adımlardan ve adımlarının yaşam döngüsü modeline göre nasıl değiştiğini bu yazı dizisinde ele alacağız.



1- Planlama

Yazılım yaşam döngüsünün başlangıç noktasıdır. İsminden de anlaşılabileceği gibi proje hakkında basit olarak plan, görev dağılımı ve fizibilite çalışması yapılır. Proje kabataslak olarak ortaya çıkar. Yazılım yaşam döngüsündeki en önemli adımlardan biridir çünkü bütün projenin temeli bu adımda atılır.


2- Analiz

Bu aşamada planlanan görevlerin yapılabilirliği incelenir ve analiz edilir. Projenin ne kadar süreceği ve risk hesaplaması yapılır. Projenin detayları dikkatli bir şekilde incelenir ve proje netlik kazanır.


3- Tasarım

Proje hakkında hangi teknolojilerin kullanılacağı tespit edilir, proje parçalara ayrılır ve bunların nasıl, kim tarafından ve ne zaman yapılacağı belirlenir. Bu aşamada oluşturulan dokümantasyon projenin başarısı için kritik bir önem arz etmektedir. Bu aşamaya yeteri kadar özen gösterilmeyen yazılım projeleri genellikle birkaç yıl içerisinde içinden çıkılamayacak bir hale gelir ve proje yeniden yazılmak zorunda kalınır. Bu elbette istenmeyen bir durumdur.


4- Gerçekleştirme (Üretim)

Eğer önceki aşamalara özen gösterilirse bu aşamada süreç zorlu geçmez. Bu aşamada, önceki aşamalarda belirlenen tasarım çizgisi ve görev dağılımı ile proje geliştirilir. Projenin test aşaması da burada yapılır. Bulunan hatalar müşteriye teslim edilmeden önce fark edilip düzeltilmelidir. Bu noktadan sonra analiz yapılmaması ve daha önceden belirlenen tasarım çizgisinde devam edilmesi projenin devamlılığı ve sağlığı için oldukça önemlidir.


5- Bakım

Yazılım yaşam döngüsündeki en uzun soluklu aşama bakım aşamasıdır. Proje tesliminden sonraki hataların giderilmesi, ürüne yeni özellikler eklenmesi, bazı özelliklerin kaldırılması ve performans iyileştirmeleri bu aşamada gerçekleştirilir. Bu aşamada kullanıcılardan gelen geri bildirimler önemlidir. Bu geri bildirimler ile iyileştirmeler yapılmalı ve gereksiz özellikler kaldırılıp yazılım daha kullanıcı dostu bir hale getirilmelidir.


Terminoloji

Yazılım yaşam döngüsü sözlük tanımı olarak bir yazılımın geliştirilmesi ve bakımı süresince icra edilen adımlar topluluğudur. Yazılım yaşam döngüsü modelleri birçok farklı ihtiyaca göre oluşturulmuştur. Tek bir evrensel model yoktur, ihtiyaçlara ve imkanlara göre en iyi model vardır. Fakat “en iyi” modeli seçmek gerekirse, günümüzde en çok kullanılan “scrum” modeli bu sıfata en uygun adaydır.


Şelale (Waterfall) Modeli

Şelale modeli modern yazılım yaşam döngülerinin temelidir. Bir zamanlar en fazla kullanılan yazılım yaşam döngüsü modeliydi. Bu modelin efektif bir şekilde kullanılması için proje kısa, istekler çok net olmalı ve değişmemelidir. Çünkü bir sonraki adıma geçmek için önceki adımların tamamlanması gerekir. Tüm adımlar bitmeden müşteriden geri bildirim alınamadığı için esnek bir yapı değildir. Modern yazılım projeleri doğası gereği eskiye göre çok daha karmaşık ve uzun soluklu olduğu için zaman içinde kullanımı azalmıştır. Ancak doğru ihtiyaçlara yönelik kullanılmaya hala devam edilmektedir.



V Modeli

Bu model şelale modeline benzer ama bazı özellikleriyle şelale modelinden ayrılır. Yine şelale modeli gibi müşterinin istekleri net ve belirgin olmalıdır. Şelale modelinden farklı olarak bu modelde test çok daha önemli bir yere sahiptir. Proje genel olarak 3 parçaya ayrılır bunlar kullanıcı modeli, mimari model ve gerçekleştirim modelidir. Bu modeldeki amaç her bir aşamada, başka bir onaylama aşamasıyla birlikte ilerlemektir.



Helezonik (Spiral) Model

Bu modeli diğer modellerden ayıran en önemli özellik risk analizi kısmıdır. Her döngü bir fazı temsil eder. Önceki modellere göre daha esnektir ve yinelemeli artımsal bir yapısı vardır. Bu modelde kullanıcı yazılım yaşam döngüsünün ilk kısmından itibaren bir rol oynar ve bu sayede çok net olmayan veya istenmeyen durumlar erken fark edilerek düzeltilebilir. Yazılımın kodlanmasına önceki modellere göre daha hızlı başlandığı için takım moralini pozitif olarak etkiler.



Artımsal Geliştirme Modeli

Bu modelin en önemli özelliği geliştirmenin ve teslimin parçalara bölünmesidir. Bu modelde ürün kat kat geliştirilir. Kullanıcıdan alınan isteklerin önemine göre proje parçalara ayrılır ve öneme göre geliştirilmeye başlanır. Bu modelin artımsal yapısı sayesinde üretim kısmı ile kullanım kısmı eş zamanlı olabilir. Kullanılabilir fakat eksik ürün kullanıcı tarafından kullanılırken aynı zamanda eksik kısımları geliştirilebilir. Kullanıcı eline erkenden bir prototip geçtiği için kullanıcıdan alınan geri bildirim doğrultusunda proje daha esnektir ve bu geri bildirim ürün için oldukça kıymetlidir.



Kodla ve Düzelt Yaşam Modeli

Genellikle kısa ve basit programlarda uygulanır. Direkt geliştirme aşamasıyla başlanır, bu durum kısa projeler için kaynak tasarrufu sağlar. Bu model uzun soluklu projeler için kullanılmamalıdır çünkü dokümantasyon eksikliği nedeniyle uzun vadede bakımı çok zor ve maliyetlidir. Genellikle yazılım kısa süre içinde emekli edilir. Kısa vadede en kolay yol gibi gözükse de uzun vadede pahalıya patlar.


Çevik Yazılım Modeli

Çevik yazılım çabuk ürün çıkarabilme, kullanıcıdan gelen isteklerin çabuk bir şekilde uygulanması ve ürünün kısa sürede teslim edilmesini amaçlar. Çevik yazılım geliştirme modelleri ile projeler hızlı, esnek ve ucuz bir şekilde geliştirebilir. Çevik geliştirilmede proje küçük yinelemelere ayrılır ve parçalar başka bir proje gibi geliştirilir (böl ve fethet yöntemi). Her bir yineleme 2-4 hafta arası sürmelidir. Bu demek değildir ki 2 haftada kısa veya 1 aydan uzun süremez, yineleme süresi projeye ve kaynaklara göre değişebilir. Her yineleme aynı zamanda bir prototip olduğundan dolayı müşteriye sürekli çalışan bir ürün teslim edilir. Bu durum hem müşteri hem ekip için daha sağlıklıdır.


Extreme Programming (XP)

XP’nin 4 temel değeri vardır. Bunlar iletişim, basitlik, geri bildirim ve cesarettir. Yazılım projelerindeki en önemli sorunlardan biri iletişim eksikliğidir. XP, iletişim adımında bunu ortadan kaldırmayı amaçlar. Bunu sıkı bir iletişim ağı ve yüz yüze görüşmelerle yapar. Basitlik XP için en önemli adımlardan biridir. Projede karmaşık olmayı gerektirmeyen her şey basit olmalıdır, bu sayede basit ve esnek bir ürün ortaya çıkar. Geri bildirim sayesinde hatalar ve eksiklikler önceden fark edilip düzeltilir. Böylelikle projenin sonuna doğru çok büyük eksiklikler ve hatalarla karşılaşılmaz. Cesaret, XP’nin esnek ve modüler yapısı sayesinde çevik olmayan projelerde yapılamayacak cesaret gerektiren büyük değişiklikler yapmamıza olanak sağlar.



Scrum

Scrum, 1990’larda Jeff Sutjerland ve Ken Schawaber tarafından geliştirilmiştir. Scrum, projeyi “sprint” adlı parçalara böler, bu yöntem kompleks bir projeyi basit parçalara indirger. Bir sprint’in süresi bir ayı geçmemelidir. Scrum’daki ikinci önemli özellik ise toplantılardır. Bu toplantılar genellikle ayakta yapılır ve 15–20 dakika sürer. Buradaki amaç uzun süren verimsiz toplantıları elimine edip iş takibini verimli bir şekilde yapmaktır. Scrum’da 3 temel bileşen bulunur. Bunlar roller, toplantılar ve bileşenlerdir.



Roller

Ürün sahibi projenin sonucundan sorumlu kişidir. Takımda kimin ne yapacağına karar verir. Scrum master, takımdaki herkesin scrum prensipleri ile çalıştığını takip eden kişidir. Scrum takımı ise projeyi scrum prensiplerine göre geliştiren geliştirici takımdır.


Toplantılar

Toplantılar scrum’da önemli bir yere sahiptir. Geleneksel toplantıların aksine scrum toplantılar kısa ve özdür. Genellikle sabah saatlerinde 15 dakika günlük scrum toplantısı, sprint başlangıcında sprint planlama toplantısı ve sprint gözden geçirme toplantısı yapılır. İyi organize edilmiş bir scrum toplantısı zaman kaybına yol açmadan, verimli bir şekilde ekibin bilgilendirilmesini sağlar.


Bileşenler

Ürün gereksinim dokümanı, ürün geliştirme sürecinde yapılacakların bir listesidir. Esnek bir listedir. Eleman ihtiyacına göre eklenip çıkartılabilir ve daha küçük parçalara bölünebilir. Genellikle kullanıcı hikayelerinden oluşur ve kullanıcı odaklı bir yapısı vardır, daha çok geliştirici odaklıdır. Sprint kalan zaman grafiği, iyi bir zaman yönetimi için oluşturulur. Sprint’te geride veya ileride ne olduğunu görmek için tutulan bir çizelgedir.


Yazılım Yaşam Döngülerinin Karşılaştırılması

Başlangıçta da bahsedildiği gibi herhangi bir yazılım döngüsü modeline en iyi demek mümkün değildir fakat her birinin öne çıktığı bazı yerleri vardır. Örneğin şelale modeli gereksinimleri çok net olan küçük projelerde uygulanabilir fakat esnek olmaması ve kullanıcı ile iletişiminin yetersiz kalmasından dolayı büyük ve değişen projelerde kullanılmamalıdır. V modeli ise şelale modelinin test odaklı bir versiyonu olduğundan şelale modelinin eksikliklerini barındırır. Değişen bir proje yapısı için önerilmez. Spiral modelde şelale modelinin birçok eksikliği giderilmiştir. Sürekli kullanıcıyı projeye dahil etmesi, detaylı dokümantasyon gibi özellikleriyle büyük projeler için idealdir, küçük projelerde ise bu kadar karmaşıklığa gerek olmadığından dolayı tercih edilmemektedir. Artımsal geliştirme modelinde kullanıcıdan sürekli geri dönüş alındığı için ileride değişebilecek ve esnek projeler için idealdir fakat bu modelin de dezavantajları vardır. Projeyi küçük parçalara önceden bölmek için proje tanımları ve istekleri çok net olmalıdır. Kodla ve düzelt modelinde en büyük sorun raf ömrüdür, dokümantasyon olmadığı için uzun soluklu projelerde kullanılamaz ve yazılım kısa sürede emekli edilir. Çevik modeller günümüzde modern yazılım projeleri için en çok kullanılan yöntemlerdir. Büyük, değişime yatkın ve müşteri tanımlamaları çok net olmayan projeler için idealdir, iletişime ve müşteri geri bildirimine yüksek önem verdiği için hataları kayda değer biçimde azaltır ama projenin bir bitiş tarihi olmadığından dolayı projeler beklenenden daha uzun sürebilir.

Scrum Günümüzde Neden Popüler?

Scrum’ın günümüzde popüler olmasının birçok sebebi vardır. Bunlardan biri istek ve tanımlamaları net olmayan müşteriyi proje başından itibaren sürece dahil ederek ileride oluşabilecek büyük sorunları önlemesidir. Projeyi küçük parçalara bölerek karmaşık olan ürünü basit sprint’lere çevirerek projeyi daha yönetilebilir bir hale getirir. Sürekli düzenlenen çabuk toplantılarla takım içi iletişimini artırır ve gereksiz uzun toplantılarla vakit kaybettirmez. Projeyi esnek ve modüler hale getirdiği için ileride yeni bir özellik ekleme, hata ayıklama, yazılımı optimize etme gibi bakım işlemlerini mümkün kılar. Bu sayede günümüzde yazılan birçok modern yazılım projesi scrum yapısını kullanmaktadır.


Kaynaklar ve İleri Okuma

1- Doç. Dr. Deniz Kılınç, Bakırçay Üniversitesi, Yazılım Temelleri Dersi.

bottom of page