Yazılım Yaşam Döngüsü nedir?
Yazılım günümüz dünyasında neredeyse her iş için en büyük gereksinimlerden biridir. Dolayısı ile başarı elde etmek için hem kaliteli hem de güvenli yazılım tartışılmaz bir öneme sahiptir. Her canlının bir yaşam döngüsü vardır. Bunu doğmak, büyümek ve ölmek gibi basitçe sınıflandırabiliriz. Hayatımızın her alanında karşılaştığımız bu döngülerle yazılımda da karşılaşmak olağandır. Tıpkı bir insan gibi yazılımın da oluşum, gelişim ve sonuçlanmadan oluşan bir döngüsü vardır. Yazılımın hem üretim hem de kullanım süreci boyunca geçirdiği her adımın toplamı yazılım geliştirme yaşam döngüsü olarak adlandırılmaktadır.
Geliştirilen ilk yazılımlarda görülen büyük eksikliklerden bazıları projelerinin zaman ve bütçe sınırını aşarak tamamlanması ve istenilen kalitede olmamasıdır. Fonksiyonellik açısından yetersizlik ve gereğinden fazla iş gücü kullanımı, kalite düşüklüğünün başlıca sebepleri arsında gösterilebilir. Bunların yanında hızla gelişen teknoloji de yazılım projelerinin yenilemesini gerektiren geri dönüşlerde bulunulmasına sebebiyet vermiştir. Bu ve bu gibi yinelemeler yazılım geliştirmenin, neden bir insan hayatı gibi doğrusal ve sonlu değil de döngüsel bir süreç olduğunu gösterir. Yazılım geliştirme yaşam döngüsü bu eksikliklerin en aza indirilmesi ve mümkünse tamamen ortadan kaldırılması konusunda büyük önem taşır. Yazılım yaşam döngüsü belli başlı aşamalardan oluşur. Bu aşamalar şunlardır:
· Planlama: Döngünün ilk aşamasıdır. Bu aşama projenin genel yürütülme planı oluşturulmasını ve risklerin tespit edilmesini kapsar.
· Analiz: Analizin amacı müşteri isteğinin doğru bir şekilde anlaşılmasını sağlamaktır. Gereksinimler incelenir ve projede istenilenler tespit edilir. Müşteri ve mühendisler arasında anlaşılıp kesinleştikten sonra dokümantasyon yapılır.
· Tasarım: Gereksinimler belirlendikten sonra bu aşamaya geçilir. Bu aşamada amaç müşterinin isteklerine ve gereksinimlerine hitap eden bir yazılım ürünü oluşturmaktır. Tasarım aşamasında soyutlama ve modelleme gibi teknikler kullanılır.
· Gerçekleştirme Aşaması: Bu aşama kodlama ve test aşamalarını barındırır. Kodlama aşaması yazılım ürününün programlanma aşamasıdır. Daha sonra ise test aşaması vardır. Test aşamasını amacı hata payını en aza düşürmek ile zaman, para ve iş gücü gibi kaynakları optimum seviyede kullanmaktır.
· Bakım: Yazılım ürünü teslim edildikten sonraki süreci kapsayan aşamadır. Bu aşamada hatalar düzeltilir, sonradan doğan ihtiyaçlara yönelik özellikler eklenebilir veya iyileştirmeler yapılabilir.
Yazılım geliştirme yaşam döngüleri belli başlı modeller halinde sınıflandırılmıştır.
Gelişigüzel Model:
1960’larda kullanılmaya başlanan bu model tam olarak bir model bile değildir. Bir yöntemi veya uyduğu herhangi bir adım sırası yoktur. Tamamen geliştiriciye bağlı olarak ilerler ve bu sebeple hem izlenilebilirliği zayıf hem de bakımı oldukça zor ve maliyetlidir. Takım çalışmasına uygun değildir, yalnızca bireysel üretilen basit ve kısa yazılım ürünlerinde kullanılır.
Barok modeli:
Bu modelde yaşam döngüsü adımları doğrusal bir şekilde gelişir. Dolayısıyla adımlar arası geri dönüşler yok veya belirsizdir. Dokümantasyon ayrı bir süreç olarak ele alınır. Yazılımın geliştirilmesi ve testinden sonra yapılması öngörülür. Bu model 1970’li yıllarda ortaya çıkmış ve kullanılmışsa da günümüzde aktif şekilde kullanılan modeller arasında yer almamaktadır.
Şelale Modeli (Waterfall Model):
Modelin ismi bir şelalenin dökülmesine benzemesinden gelmektedir. Bu modelin özelliği yeni bir faza geçmeden öncekinin tamamen tamamlanmış olmasıdır, yani yazılım süreci doğrusaldır. Aşamalar arası çakışma olmaz ve her safhada dokümantasyon vardır. Dokümantasyon bu model için modelden bağımsız bir süreç değil de modelin bir parçasıdır. Müşterilerden alınan istek ve gereksinimler sadece başlangıç safhasındadır, kodlama ve tasarım safhasında buna rastlanmaz. Bu sebeple süreç bittikten sonra kullanıcıdan gelen geri bildirim artabilir, bu da maliyeti yükseltir.
Bu modelin negatif yanlarından biri fazların birbirinden kesin olarak ayrılmasıdır, bu sebeple hem model değişime açık değildir hem de hataların tespiti uzun zaman alabilir. Hataların tespiti ne kadar gecikirse maliyet o kadar yükselir. Ayrıca müşteri ile tasarım ve sonraki aşamalarda diyalogda olmamak da müşterinin gereksinim ve isteklerini tam olarak yerine getirebilmeyi zorlaştırır. Bu sebeplerden ötürü kısa sürede bitebilecek ve müşteri tarafından çok açık ve net tanımlanmış projeler için uygundur. Geleneksel yazılım geliştirme modeli olarak bilinmektedir ve günümüzde kullanımı oldukça azalmıştır.
V Model:
Şelale modelinin gelişmiş halidir. Doğrusal bir yönde ilerlemez, bunun yerine süreç adımları kodlama evresinden sonra yukarıya döner ve V şeklini oluşturur. Sol tarafı üretimi, sağ tarafı ise sınama işlemleri ile ilgili aşamalardan oluşmaktadır. Her bir üretim aşamasının karşısında bulunan sınama aşamaları sayesinde hataları yakalamak ve çözümlemek daha kolaydır. Yine çağlayan modelde de olduğu gibi belirsizliklerin az ve gereksinim tanımlamalarının net olduğu projelerde V süreç modeli uygun bir model olarak ele alınır. Bu yöntemde proje takibi kolaydır. Modelin kullanımı genel olarak basittir.
Kodla ve Düzelt (Coding and Fix ):
Adından da anlaşıldığı üzere kodlama ve düzeltme işlemi eşzamanlı gerçekleşir, yazılım ürünü kodlanmaya devam edilirken bir yandan da hatalar tespit edilir ve düzeltilir. Genellikle kısa ömürlü projeler ve prototipler için uygundur. Uzun ve kapsamlı projelerde kullanılmaz çünkü hazırlık aşaması yoktur bu yüzden kolaydır ve herkesin kullanabileceği bir modeldir. Ancak bu modelin kontrolü zordur. Maliyet planlaması yoktur ve tam olarak ne zaman biteceği öngörülemez. Herhangi bir planlama aşaması veya dokümantasyon içermediğinden hataların bulunması ve ileri zamanlarda geri dönülüp düzeltilmesi, bakım yapılması oldukça zordur. Bireysel geliştiriciler için uygun olsa bile takım çalışmaları ve kapsamlı projeler için kullanılması doğru değildir.
Spiral (Helezonik) Model:
Bu model 4 ana aşamadan oluşur. Bunlar planlama, risk analizi, üretim ve kullanıcı değerlendirmesidir. Bir spiral oluşturacak şekilde döner ve bu aşamaları tekrar eder. Maliyet ve kaynak tahminleri kapsamlı bir planlama ve risk analizi yapıldıktan sonra üretime geçilir. Daha sonra müşteri değerlendirmesine sunulur ve sonraki spirale geçmeden önce müşteriden geri bildirim alınır. Sürekli tekrarlanan spiral yapı ürünün elde edilmesi için ayrılan zamanın uzamasına sebep olur. Bu modelin en büyük dezavantajlarından biri maliyettir. Ayrıca spiral model küçük ve risksiz projeler için çok pahalı, karmaşık ve uzun sürelidir, bu yüzden tercih edilmemelidir. Bu model daha çok belirsiz ihtiyaçları olan, büyük ve karmaşık projeler için uygundur çünkü risk analizinin ön planda olması hataları erken giderme fırsatı tanır.
Prototipleme :
Prototip yazılım ürününün bazı özelliklerine sahip bir ön çalışma, modeldir. Gerçek yazılımla tamamen aynı olması beklenemez fakat kullanıcının eksik kalan gereksinimlerini tespit etmeye yardımcı olur. Ayrıca kullanıcıların, yazılımcıların tekliflerini değerlendirmesine ve önceden deneme şansı bulmasını sağlar. Geliştirme sürecine müşteri bizzat dahil olduğu için geri bildirim hızlıdır, dolayısı ile müşterinin istek ve ihtiyaçlarına daha iyi cevap verebilen yazılım ürünleri geliştirilmiş olur. Kullanıcı sınırlı sayıda olmak üzere prototipi her denemesinden sonra geri bildirim verir. Alınan geri bildirimlere uygun olarak ürünün üzerinde yenilemeler ve değişiklikler yapılır. Yazılım müşteri ve geliştirici arasında periyodik bilgi gidip gelmeleri sonucunda geliştiğinden prototipleme de spiral model gibi döngüsel bir süreçtir. Bu modellemenin dezavantajlarından biri prototiplerin dokümantasyonunun olmamasıdır. Ayrıca müşteri prototipten de son ürün gibi bir beklenti içinde olacağından memnuniyet sağlamak zordur.
Evrimsel Geliştirme (Evolutionary Development):
İlk tam ölçekli modelleme türüdür. Pilot uygulama kullan, test et, güncelle diğer birimlere taşı şeklinde dört aşamadan oluştuğu için modelin tamamının başarısı ilk evrimin başarısı ile doğru orantılıdır çünkü ilk evrim diğer her birime aynen taşınır. Her aşamada üretilen ürünler, üretildiği alan için tam işlevselliği içerir. Özelikle büyük alanlara yayılmış büyük firmalara önerilir. Örnek olarak bankalar verilebilir. Bu modelleme üründe en net anlaşılan gereksinimlerle başlanılıp, müşteri tarafından istenen diğer özellikler süreç boyunca üzerine eklenir. Dolayısı ile gereksinimleri anlamayı kolaylaştırır, böylece risk ve hata oranı da azalır. Fakat değişikliklerin denetimine sahip değildir bu yüzden bakımı hem zor hem de diğer modellere göre maliyetlidir. Sürekli kullanıcıdan alınan geri bildirimler ile ilerlendiğinden ürünün tamamlanması uzun zaman alacaktır. Diğer modellere göre daha yavaştır.
Artımlı Geliştirme (Incremental Development):
Artımlı geliştirme modeli bir müşterinin ürününde değişikliğe ihtiyacı olduğunda bu değişime ayak uydurur. Artımsal model yazılımı parça parça geliştirip parça parça teslim etmeye dayanır. Parçaların bölünmesine ise müşterinin gereksinimlerinin önceliğine göre karar verilir. Her bir parça öncekinin üzerine bazı ek işlevlerin eklenmesi ile oluşur. Her teslimden sonra kullanıcıdan geri dönüş alındığından ürünün işlevselliği bir o kadar erken anlaşılır. Bir önceki teslim edilen parça bir sonraki için prototip görevini üstlenir. Artımsal model, geliştirilen yazılımın az sayıda kişiyle tamamlanması istendiği taktirde uygun bir yazılım geliştirme modelidir. Üstelik geliştiriciler de her artırımla berber tecrübe kazanmış olur. Artırımlı geliştirme modelinde bir taraftan üretim yapılır bir taraftan da kullanım başlar. Bu model yinelemelidir, yeniden kullanılabilir ürün tüm döngülerin sonunda ortaya çıkar. Özellikle uzun zaman alabilecek ve sistemin işlevselliğinde eksik görülebilecek türdeki yazılımlar bu model ile geliştirilmeye uygundur.
Çevik Yazılım Geliştirme
Zaman içinde yazılım ürünlerinin zamanında ortaya çıkarılamaması, yenilik ve değişiklik isteklerine çabuk cevap verilememesi ve üründeki hatalarının geç fark edilmesi gibi sorunlar yazılım sektöründe kendini göstermeye başlamıştır. 1990lı yılların sonunda ise yazılım dünyasında, kullanıcıların daha kaliteli ürünlere daha ucuz ve daha kısa sürede ulaşmak istemesi, “Çevik” adı verilen metotlar geliştirilmeye başlanmasına yol açmıştır. Bu metotların amacı değişen ihtiyaçlara daha hızlı yanıt vermek ve yüksek performanslı, en az riskli ve maliyeti en düşük çözümler oluşturmaktır. Çevik Model’in kullanım alanları; erken geri bildirim gerektiren ve küçük fonksiyonel parçalara bölünmesi kolay olan projelerdir. Çevik metotlar da kendi içinde çeşitli metodojilere ayrılır. Çevik yazılım geliştirme metodolojisi sık kullanılan bir yazılım geliştirme metodolijisidir. Bu metalojide projenin büyüklüğünden bağımsız olarak proje kendi içinde küçük yinelemelere ayrılır. Bu parçalama işlemi her hangi bir hatada geri dönüp bu hataların düzeltilmesini kolaylaştırır. Müşterinin proje devam ederken isteyebileceği bir değişiklik durumunda bile süreç süresince yazılımın zaman kaybı olmaksızın devam etmesi gerekmektedir. Her yineleme kendi içinde bir proje olarak geliştirilir. Her yinelemenin sonunda geliştirici ekip tarafından kullanıcıya ilerleme hakkında bilgi verilir. Her bir yineleme yaklaşık 2 ila 4 hafta arası sürer ve her yinelemenin sonucunda müşteriye çalışan bir yazılım teslim edilir ki bu müşteri memnuniyeti için oldukça önemlidir.
Çevik Yazılım Geliştirme Manifestosu
On yedi yazılımcı 2001 yılında Amerika’nın Utah eyaletinde bir araya gelip yazılım geliştirme ile alakalı 2 günlük bir beyin fırtınası yaptılar. Toplantının amacı yazılım geliştirme üretkenliğini arttırmak, bu doğrultuda da farklı tecrübe ve yaklaşımları değerlendirmekti. Toplantı sonucunda fikir birliğine varılan ve toplantının bir çıktısı sayılabilecek 4 maddelik bir değerler topluluğunu Çevik Yazılım Geliştirme Manifestosu ismi ile yayınladılar. Bu manifesto geçtiğimiz 15 yıllık süreçte yazılım projelerinde elde edilen başarının artması için hedef ve vizyon halini alarak bir akıma dönüştü. Bu manifestoda kısaca;
Süreçler ve araçlardan ziyade bireyler ve aralarındaki etkileşimlere Kapsamlı dokümantasyondan ziyade çalışan yazılıma Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye değer ve önem verdikleri dile getirilmektedir. Burada dikkat edilmesi gereken kısım sağ taraftakilerin tamamen göz ardı edilmemesi, sadece soldakilerin daha fazla önem arz ettiğidir.
Çevik Yazılım Geliştirme Prensipleri
İlk ve en önemli öncelik müşteri memnuniyetidir. Yazılımın erken ve devamlı teslimi ile müşteri memnun edilir. Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilebilir hatta edilmelidir. Çalışan yazılım olabildiğince kısa süre aralıkları ile tercihen birkaç haftada bir müşterinin deneyimine sunulmalıdır. İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdır. Projenin temelinde çalışanların motivasyonu önemlidir, onlara gerekli her türlü destek ve güven duygusu sağlanmalıdır. Etkin iletişim adına takım çalışanlarının yüz yüze iletişimi önemli rol oynar. Sadelik ve basitlik önemlidir, işin özünde olmayan hiçbir şey yapılmamalıdır. En iyi projeler, gereksinimler ve tasarımların kendi kendini örgütleyen takımlardan ortaya çıktığı bilinmeli ve ona göre hareket edilmelidir. Takım çalışanları, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.
Extreme Programming (XP)
En popüler çevik yazılım geliştirme süreçlerinden biridir. Extreme programming ile oluşturulan süreçte müşteri ve müşterinin gereksinimleri başroldedir. Bu metotla yazılım ürününün oluşturulması esnasında tam belli olmayan ve çabuk değişen müşteri gereksinimlerine ayak uydurulabilir. Bu diğer modellerde mümkün değildir çünkü müşterinin gereksinimlerinin tamamı yazılım aşamasından önce alınır ve belgelenir. Proje ilerledikçe müşteri tarafından yapılması istenen değişikliklerin maliyeti çok yüksek olacaktır, çünkü mevcut tasarım istenilen değişiklerin yapılmasını engelleyebilir ya da tamamen yeni bir tasarım gerektirebilir. Çevik olabilmek için az yükle yola çıkılması gerektiği düşüncesi ile proje öncesi geniş çapta tasarım ve dokümantasyon oluşturulmasına izin verilmez. Extreme programming’in dört temel prensibi vardır: bunlar İletişim, Basitlik, Geri Bildirim ve cesarettir. XP’de iletişim yüz yüze olmalıdır, bu ekip üyelerinin kendi içindeki sağlıklı iletişimini destekler. Sadece ekibin üyelerinin kendi arasında değil müşteri ile de sıkı bir iletişim içinde olması beklenir. Bu hataların daha erken fark edilmesi için oldukça önem arz eder. Bakıldığında kolay gözükse de sağlanması zor maddelerden biri basitliktir. Basitlik gereksiz her şeyden kaçınılması yani sadece zorunlu işlerin yapılmasıdır.
XPnin amacı esnek ve basit bir sistem olduğundan karmaşık çözümler XP ile bağdaşmamaktadır. Geri bildirimler sağlıklı bir yazılım ürünü oluşturmanın en temel şartıdır, bu sayede hem hatalar çabuk fark edilir ve düzeltilir em de kullanıcıya daha iyi bir deneyim sunulmuş olur. XP’de müşteri de yazılım ekibinin bir üyesi olarak görülür. Yönetici ve diğer tüm yazılım ekibi çalışanlarının düşünceleri de önem sahibidir. Cesaret prensibinde ise amaç başarısızlıktan korkmak yerine başarısızlığı oluşturan nedenler üzerine gitmek ve bunları çözmektir. Bu aşamada ekibin üzerinde oluşan baskı sebebi ile bu da zor bir prensiptir. Konu sadece başarısızlıktan öte, başarısızlık sağlanırsa sıfırdan başlama cesareti ile de ilgilidir. Başarısızlık durumunda amaç bunu en kısa sürede çözüp telafi etmek olmalıdır. Başarısızlıktan korkmak ciddi zaman kayıplarına yol açar ve bu XP için kabul edilebilir kayıp değildir.
SCRUM
Scrum, 1990’ların ortalarında, Jeff Sutjerland ve Ken Schawaber tarafından geliştirilen çevik proje yönetim metodolojilerinden biridir. Kompleks ve karmaşık yazılım süreçlerinin yönetilmesi için kullanılır. Bunu yaparken bütünü parçalayan, tekrara dayalı bir yöntem izlenir. Amaç düzenli geri bildirimler ve planlamalar eşliğinde hedefe ulaşmaktır. Bu anlamda ihtiyaca yönelik ve esnek bir yapısı vardır. Müşteri ihtiyacına göre şekillendiği için müşterinin geri bildirimine göre yeniden yapılanmayı sağlar. Bu metodoloji kapsamında iletişim ve takım çalışması çok önemlidir. Scrum’da sıkça kullanılan bazı kavramlar vardır. Bunlar product backlog (gereksinim listesi), Sprint Backlog (projenin bir parçası ve ona ayrılan zaman) ve Scrum Daily Meeting (günlük toplantı) ’dir. Ayrıca üç temel kavram vardır; bunlar roller, toplantılar ve bileşenler/araçlardır.
· Scrum’da ürün sahibi, Scrum yöneticisi ve Scrum takımı olmak üzere üç farklı rolden söz edilebilir. Ürün sahibi geliştirme takımı ve müşteri arasındaki iletişimi sağlar. Product backlog’u oluşturur ve eğer isterse sprinti iptal etme yetkisi vardır. Scrum master Scrum kurallarını, teorilerini ve pratiklerini iyi bilir ve takımın bu kurallarını uygulamasından sorumlu kişidir. Takımını rahatsız eden ve onların verimini düşürecek etkenleri ortadan kaldırır. Scrum takımı sprint backlog’u oluşturur. Kendi kendilerini yönetir ve birinin sürekli iş vermesini beklemezler, kişilerin tek bir görevi yoktur. Çapraz görev dağılımı yapılır ve herkes her işi yapabilecek konumda bulunur. Genellikle bu ekibin üye sayısı 5–7 kişi arasında değişiklik göstermektedir. Projenin geliştirilmesindeki ana sorumluluk geliştirme takımının kendisine aittir.
· Scrum’da toplantılar da üç ana başlık altında ele alınır. Bunlar Sprint Panning (sprint planlama), Sprint Rewiev (sprinti gözden geçirme) ve Daily Scrum Meeting (gümlük Scrum toplantısı)’dir.
· Bileşenler ve araçlar ise Product Backlog (Ürün Gereksinim Dokümanı), Sprint Backlog (Sprint Dokümanı) ve Burndown Chart (Sprint Kalan Zaman Grafiği)’dır.
Scrumun günümüzde popüler olmasının sebeplerinden en ön önemlisi geliştirici ekip üyelerinin birbiri ile iletişimini güçlü tutması ve dolayısıyla iletişimde aksaklıklar yaşamadan sağlıklı bir proje oluşturmasıdır. Bunun yanında müşteri ile sürekli diyalog halinde olmak da Scrum’un artılarından biridir. Bu sayede geleneksel ve doğrusal modellere kıyasla hem müşterinin istek ve ihtiyaçlarına daha kapsamlı cevap verebilir hem de riskler ve ilerde oluşabilecek hatalar en aza indirgenmiş olur. Ayrıca bu yakın iletişimin bir sonucu olarak müşteri kendini daha iyi ifade edebilir ve tam olarak istediği ürünü elde edebilir. Dokümantasyon süreci kalabalık olmadığından takip etmek kolaydır. Hatalar en aza indirgendiğinden bakım ve yenileme maliyetleri çok yüksek değildir. Bu sebeplerin tamamı bizleri Scrum’un neden günümüzde tercih edilen bir metodolojiden biri olduğu sonucuna götürür.
Kaynakça
https://www.emo.org.tr/ekler/0801491e6797bbd_ek.pdf
https://webdosya.csb.gov.tr/db/cbs/icerikler/salihsoylu_tez_v10-20180925134450.pdf
https://fikirjeneratoru.com/yazilim-proje-yonetimi-yontemleri/
https://furkanalniak.com/yazilim-muhendisligi-yazilim-surec-modelleri/
https://blog.burakkutbay.com/cevik-agile-yazilim-gelistirme-metodu-nedir.html/
https://blog.burakkutbay.com/cevik-agile-yazilim-gelistirme-metodu-nedir.html/
https://medium.com/@ahmetuyar/extreme-programming-xp-nedir-ddc003a515c4
https://medium.com/@secilcor/scrum-nedi%CC%87r-6a4326951dd8
Doç. Dr. Deniz Kılınç’ın Yazılım Mühendisliği Temelleri ders notları.
