YAZILIM YAŞAM DÖNGÜSÜ (SDLC) VE MODELLERİ
Özet olarak:
Bu yazımızda, yazılım yaşam döngüsünü ele alacağız. Aynı zamanda da yazılım yaşam döngüsünün temel adımları, yazılım yaşam döngüsündeki süreçler, bu süreçlerde kullanılan modellerin neler olduğu, kullanılan modellerin artılarının ve eksilerinin ne olduğundan bahsedeceğiz. İncelenen modeller arasında karşılaştırmalar yapıp hangi modelin ne zaman daha mantıklı olduğu hakkında düşüncelerimi paylaşacağım.
Yazılım Yaşam Döngüsü Nedir?
Yazılım yaşam döngüsü, (Software Development Life Cycle SDLC) yazılımın hem üretim hem de müşteri tarafından kullanımı süreçlerinde devam eden yazılımı geliştirmek için geçirdiği aşamaların tümüne verilen isimdir diyebiliriz. Bu süreçte zaman zaman kullanıcı ihtiyaçları ve ürün hataları ortaya çıktığı için, süreç hiçbir zaman tek yönlü olmayıp geriye dönüşlerin yapıldığı, tekrarlar ile sorunların çözüldüğü veya yeni özelliklerin elde edildiği bir döngü halini alır. Bu döngüler sayesinde yazılımın gelişimi daha rahat ve planlı bir hal alır. Bu döngüdeki bazı temel adımlar sayesinde zaman ve ekonomi yönetiminde daha hâkim olduğumuzu söyleyebiliriz.
Yazılım yaşam döngüsünün temel adımlarını genel olarak aşağıdaki gibi sınıflandırabiliriz:
· Planlama (Planning)
· Analiz (Analysis)
· Tasarım (Design)
· Gerçekleştirme (Implementation)
· Bakım (Maintenance)
1. Planlama Aşaması:
Bu aşamada üretilecek olan ürün için müşteriden müşterinin gereksinimleri alınır ve ürün için fizibilite çalışması yapılır. Bu çalışmalardan sonra planlamalar yapılır ve süreç başlamış olur.
2. Analiz (Çözümleme) Aşaması:
Buradaki temel amaç yazılım mühendisi açısından mevcut yapılan plandaki çözümün incelenip müşteri isteğinin doğru bir şekilde anlaşılıp anlaşılmadığının ortaya çıkarılmasıdır. Bu aşamada gereksinimler detaylı bir şekilde incelenir ve projede nelerin istenildiği ile ilgili analiz çalışmaları da yapılır. Daha ayrıntılı bir şekilde yapılan problem tanımlama aşamasıdır da diyebiliriz. Her şey iki tarafça açıkça anlaşılıp kesinleştikten sonra dokümantasyon yapılır. İki tarafta oluşan iletişim kopukluklarında yazılım mühendisi ve müşteri aynı ortamda birlikte çalışmalar yapabilirler. Bu süre zarfında iki tarafta birbirini anlayıp problemi daha rahat çözümleyebilir.
3. Tasarım Aşaması:
Gereksinim açıkça tanımlandıktan sonra başlanması gereken aşamadır. Bu aşamada tasarımlar yapılır. Tasarımlar mantıksal ve fiziksel tasarım olarak ikiye ayrılır.
Mantıksal Tasarım: Önerilen sistemin yapısını anlatır. Olası örgütsel değişiklere önerilir.
Fiziksel Tasarım: Yazılımı içeren bileşenler ve bunların ayrıntılarını içerir.
4. Gerçekleştirme Aşaması:
Kodlama ve test aşamaları yapıldıktan sonra kurulumun yapıldığı aşamadır.
5. Bakım Aşaması:
Teslim edilen projenin artık bakım aşaması proje yaşamı boyunca sürecek şekilde başlamış olur. Bu aşamada proje için varsa hatalar düzeltilir, iyileştirmeler yapılır, ürün için istenilirse yeni özellikler eklenir.
YAZILIM YAŞAM DÖNGÜSÜ MODELLERİ
Yazılım yaşam döngüsü sürecinde yazılımın gelişme safhasında geçirilen süreçler, temel adımları aynı olmak koşuluyla bazı modellere ayrılmıştır. Ayrılan modeller gelişme sürecinde nasıl bir aşamanın takip edileceğini, hangi düzen veya sıranın izleneceği, sürecin nasıl uygulanacağı hakkında sektöre bilgiler vermektedir. Sürecin bu tarzda farklı modellere ayrılması proje yönetimini karmaşıklık ve büyük krizlerden kurtarıp, yönetim ve işleyiş anlamında kolaylıklar sağlamaktadır. Modeller ilgili olduğu dönemin donanım ve teknolojileri ile dönemin ihtiyaçları çerçevesinde ortaya çıkmış ve önemli rol oynamıştırlar. Özetle modeller yazılım sektöründe yol gösterici bir rehber rolü oynamaktadırlar. Modeller üretilen ürün için zaman zaman farklılık gösterebilir. Bu dönemlerde doğru model ve yöntemi seçmek, zaman ve ekonomi yönetimi açısından oldukça önemlidir. Deneyimlerin ortaya koyduğu bir diğer somut örnekse doğru modellerle yönetilen süreçlerin her zaman daha kaliteli ürün ortaya sürdüğüdür.
Bu modeller iki temel kısma ayrılmıştır. Geleneksel ve çevik yazılım süreç modelleri olarak ikiye ayrılmıştır.
Geleneksel Yazılım Süreç Modelleri:
Gelişigüzel Model:
Aslında bu yöntemi model olarak isimlendirmemiz doğru olmaz. Kişisel bir yöntemdir denilebilir. Gelişigüzel geliştirme aşaması için herhangi bir model veya takip edilecek yol yoktur. Kişiye özel değişebilir yöntem ve metotların olduğu bir yol izlenir. Tek kişilik üretim ortamlarında görülen, basit programlamalar için kullanılan bir yoldur. Programı yazan kişi bile ileri zamanlar içerisinde geriye dönüp baktığında ne yaptığını anlayamayabilir. Bu nedenle ürünün bakım yapılabilirliği neredeyse imkansızdır. 1960 ‘lı Yıllarda basit programlamalar için kullanılmıştır.
Barok Modeli:
1970'li Yılların ortalarında ortaya çıkan bu model yaşam döngüsünün temel adımlarını doğrusal bir biçimde gerçekleştirmeyi öngörmektedir. Modelin en önemli özelliği ise belgeleme olgusunu ayrı bir süreç olarak ele almasıdır. Belgeleme sürecini yazılım geliştirme aşamasından sonra yapılmasını ele almıştır. Günümüzde belgeleme her süreçte kullanırken sadece 1 aşama olarak ele alınması modelin zayıf yönlerindendir. Ayrıca model de geri dönüşler hakkında bilgiler verilmemesi de eksi yönlerinden bir tanesidir.
Çağlayan Yaşam-Döngü Modeli (Şelale-Waterfall):
1970'li Yıllarda ortaya çıkan bir modeldir. Üretim sürecindeki temel adımları baştan sona en az bir kez izleyerek gerçekleşmektedir. Gereksinimleri iyi tanımlanmış ve kısa vadede üretilebilecek olan projeler için oldukça uygun bir modeldir. Barok modelinin aksine belgelemenin bir süreç aşamasından ziyade üretimin her aşamasında bulunup yapılması gerektiğini öngörür. Her aşama bir önceki aşama tamamlanmadan başlayamaz. Eğer ürün gereksinimleri iyi tanımlanmamış veya üretim süresi uzun sürecekse model işe yaramaz. Barok modelinin geri dönüş belirsizlikleri burada yoktur.
Genelde yazılımın kullanıcıya ulaşma zamanı uzun olduğu için bu modelde sorunlar yaşanabilmektedir.
Çoğu zaman gereksinim tanımlamaları kesin bir şekilde netleştirilemez. Bu kesinliğin olmaması nedeniyle hata ancak gerçekleştirme aşamasına gelindiğinde anlaşılabilir ve bu da epey zaman kaybına ve maliyete yol açar. Aynı zamanda bu hatalardan kaynaklı zaman kayıpları iş ortamında çalışanların motivasyonunu düşürürken müşteriye karşı da firmanız adına kötü bir imaj çizer.
V Süreç Modeli:
Bu modeli çağlayan modelin uyarlanması olarak düşünebiliriz. Model V harfini andırırken 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 hata kaynaklarına dönüş daha kolaydır.
Modelde temel çıktılar olarak: kullanıcı modeli, mimari model ve gerçekleştirim model olarak isimlendirilmiş üç alt model vardı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.
Helezonik (Spiral) Model:
Risk analizi konusunun özenle üzerinde duran bir modeldir. Ürettiği Prototipler sayesinde yinelemeli artırımlı bir yaklaşımı vardır.
Planlama, risk analizi, üretim ve kullanıcı değerlendirmesi adında 4 ana aşamadan oluşup tekrarlanır. Tekrarlanırken yaptığı her bir tekrara faz denir. Bu fazlar esnasında risk analizlerinin ardından kullanıcıdan olumlu ya da olumsuz yanıt almak için, ürünün prototipi üretilip kullanıcıya sunulur. Her sunumun ardından alınan değerlendirmeler sonucu yeni geliştirilmiş planlarla yeni bir faza başlanır.
Modelin en önemli avantajlarından bir tanesi kullanıcı katkısının üretimde önemli bir pay sahibi olmasıdır. Bu katkı sayesinde ürün kullanıcının isteklerinin tamamına yanıt verebilirken, üretim esnasında da hatalar oldukça erken fark edilerek zaman ve maliyet kaybı önlenmiş olur.
Helezonik model komplike bir yapıya sahiptir. Spiral bazen sonsuza dek sürebilir. Bu süreçte belgelemeler oldukça fazla olacak ve karmaşıklık daha da artacaktır. Küçük ve düşük riskli projeler için pahalı bir modeldir.
Artırımlı Geliştirme Süreç Modeli:
Ürünü tek seferde teslim etmek yerine her yazılım sürümünde yeni işlevler eklenerek teslim edilen bir modeldir. Kullanıcı gereksinimleri önceliklerine göre parçalanıp yeni sürümlerde parça parça eklenerek devam edilir. Bu süreçte ürün bir tarafta kullanılırken diğer kısımda ise hala ürünün gelişimi devam etmektedir. Üretimi uzun sürecek ve eksik gereksinimlere rağmen çalışabilecek projelerde uygun bir modeldir.
Modelde ürün gelişim safhasında bir taraftan da kullanıcı tarafından kullanıldığı için hata riski düşerken, ürün işlevselliği erken aşamalarda oluşmaya başlar. Projedeki erken teslimler, sonraki teslimler için gereksinimleri belirmede prototip görevi görür. Projenin tümden batma riski düşürülmüş olur.
Araştırma Tabanlı Süreç Modeli:
Yap-at prototipi olarak bilinen bir modeldir. Bütün anlamıyla belirsizliklerin bulunduğu çalışmalarda kullanılır. Sonuçları kestiremeyebilirsiniz. Bu sebeple maliyet hakkında planlamalar da yapamazsınız.
Evrimsel Geliştirme Süreç Modeli:
Müşterinin isteklerinin anlaşılmadığı zamanlarda kullanılan modeldir. Müşteri ile birlikte yapılan çalışmalar sonucunda taslak bir sistem oluşturulur. En net anlaşılan gereksinimlerle başlanılıp, müşteri tarafından talep edilen yeni özellikler süreç boyunca eklenir. Modelin başarısı ilk evrimin başarısına bağlıdır.
Model, kullanıcının gereksinimlerinin ne olduğunu anlamasında yardımcı olur. Sürekli değerlendirmeler geliştirme risklerinin azaltır. Buna bağlı olarak hatalar azalır.
Sürecin görünürlüğü ve izlenebilirliği zordur. Sürekli bir değişim söz konusu olduğu için yazılım yapısı zarar görebilir. Gereksinimler değiştirilmek zorunda kalabilir. Bu problemler bakımı zorlaştırır.
Kodla ve Düzelt Yaşam-Döngü Modeli:
Küçük yapıdaki programlar için kullanılan bir modeldir. Ürünü direkt gerçekleştirilmeye odaklanılmıştır. Belgeleme yapılmaz. Belgelemelerin yapılmamasından dolayı bakımı zordur.
Çevik Yazılım
Gelişen teknolojilerle büyüyen 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, yazılım sektöründe çevik yöntemlerin gelişmesine yol açmıştır. Bu yöntemlerin amacı, geliştirme sürecindeki bazı yüklerden kurtularak sonuca daha hızlı ulaşıp, değişen ihtiyaçlara daha erken cevap vermektir. Aynı zamanda yüksek performans sağlayan, hata riski en az ve ucuz yollu çözümler oluşturmak da olduğunu söyleyebiliriz.
Çevik geliştirme metodu; değişimi, parça parça yazılım teslimatını, birlikte uyumlu çalışmayı, test odaklı yazılım geliştirilmesini ve uyumlu planlamayı teşvik eder. Birlikte çalışmayı teşvik eden bu metot yazılımcı arkadaşların da morallerini yüksek tutmayı sağladığı için üretim daha kolay ve hızlı bir şekilde devam ederken sonuca gelindiğinde kaliteli ürünler elde edilir.
Extreme Programming (XP) ve Scrum en popüler iki yöntemdir.
Extreme Programming (XP):
1999 Yılında Kent Beck tarafından ortaya çıkarılmış; iletişim, basitlik, feedback ve cesaretlendirme üzerine kurulmuş bir yazılım geliştirme disiplinidir. Disiplinde takım çalışması söz konusudur. Takım arasındaki iletişimde yapılan geri dönüşlerle çalışmanın nerede olduğu görülebilir ve çalışma temposunu duruma göre ayarlayabilirler.
Extreme programming’in 4 temel değer üzerine kurulduğunu söylemiştik. 4 temel değeri incelediğimizde bu disiplinin nasıl başarıya götürdüğünü aslında görebiliriz.
İletişim: Proje çalışmalarında çoğu zaman yaşanan en büyük problemlerden birisi de ekipteki insanların birbirleri ile tam olarak anlaşamaması. XP projelerde yaşanan bu problemi ortadan kaldırmayı ve sağlıklı bir iletişimi amaçlar. Bu yüzden XP de iletişim yüz yüze ve anlaşılır olmalıdır. Oluşabilecek bilgi eksikliklerinde proje hızı düşürülmeden bilgi elde edilmeli ve ekibe iletilmelidir.
Basitlik: Yapılması gereken işler karmaşıklıktan uzak ve en basit bir şekilde çözülmelidir. XP esnek ve basit bir sistem ile gereksinimleri karşılamayı amaçlar.
Feedback: Geri bildirimler sayesinde projede ortaya çıkabilecek hatalar ortadan kaldırılır. Bu geri bildirimler müşteri, yönetici ve diğer proje çalışanları tarafından yapılabilir. Müşteri ve yazılım ekibi de belirli aralıklarda buluşup projede gelinen noktaya kadar inceleyip sonrası için oluşabilecek anlaşmazlıkları ortadan kaldırırlar.
Cesaretlendirme: Bir ürün ortaya koyarken en büyük korkumuz “Acaba sonuca doğru bir şekilde ulaşabilir miyim?” korkusu oluyor. Ve bu korku bazen yapmamız gereken şeyleri yapmamamız için bize bir engel olabiliyor. XP de bu engellerin gereksiz olduğunu ve yazılımcının hata yapmaktan korkmaması gerektiğini savunur. Oluşabilecek bir başarısızlıktan sonra onu en kısa sürede telafi etmenin daha doğru bir yaklaşım olduğunu önerir.
XP yazılım geliştirme disiplini esnek ve basit bir yazılım geliştirmek için 12 pratik yönteme sahiptir.
· Planlama Oyunu,
· Ekipte Müşteri,
· Önce Test,
· Basit Tasarım,
· Çiftli Programlama,
· Sürekli Entegrasyon,
· Kısa Aralıklı Sürümler,
· Yeniden Yapılandırma,
· Ortak Kod Sahiplenme,
· Metafor,
· Kodlama Standardı,
· Haftada 40 Saat.
SCRUM:
Çevik yazılım geliştirme yöntemlerinden bir tanesi olan scrum kompleks yazılım süreçlerinin yönetilmesinde kullanılır. Adını rugby sporundaki bir hücum taktiğinden alan bu metot iletişime ve takım çalışmasına oldukça dikkat eder. Rugbydeki mantığı da tüm takım oyuncularıyla birlikte karşı sahaya taşınarak atak yapması olan scrum takım oyununa epey bir önem veriyor.
Scrum metodunda, projenin ilerleyiş süreci, sorunları ve gelişmeleri izlenebilir bir yapıya sahip olmalıdır. Proje ilerleyişi düzenli olarak kontrol edilebilir olması gerekirken, proje yapılabilecek herhangi bir değişikliğe uyum sağlayabilmelidir.
Kompleks yapıdaki işleri küçük birimlere bölerek geliştirmeyi ön gören bu metot, karmaşık ortamlarda adım adım çalışan yazılım geliştiricileri için epey bir uygundur. Gereksinimleri açık bir şekilde tanımlanmamış, karmaşıklığı giderilmemiş projeler için en uygun modelin scrum olduğunu söyleyebiliriz. 30 Günü aşmayan günde 15'er dakikalık toplantılar ile iş takibi yapılır.
3 Temel kavram üzerinde duran Scrum bu kavramlar çerçecesinde hareket etmektedir.
1)Roller:
-Ürün sahibi: Projede geri dönüşlerden sorumlu müşteri veya müşteri temsilcisi.
-Scrum yöneticisi: Takımın Scrum metoduna bağlı kalmasını sağlayan, organizasyonları Scruma adapte eden kişi
-Scrum takımı: Birbirleri ile devamlı iletişim halinde hedefe birlikte ilerleyen Scrum metoduna uyum sağlamış takım.
2) Toplantılar
-Sprint (Koşu) Planlama: Gereksinim listesinin çıkarılıp küçük birimlere bölünmesinden sonra takımlara uygun bir şekilde dağıtım yapılır. Risk değerlendirmeleri ve risk kontrollerinin belirlenmesi gerçekleşir. Geliştirme araçları ve altyapısı onaylanır. Dağıtım, geliştirme ve pazarlama maliyetleri hesaplanır.
-Sprint (Koşu) Gözden Geçirme: Her sprint sonunda yapılan bu toplantılarda yapılan sprint gözden geçirilir ve ortaya çıkan ürün değerlendirilir. Amaç yazılımın ürün sahibinin gereksinimlerine uygun bir şekilde geliştirildiğinden emin olmaktır.
-Günlük Scrum Toplantısı: Her gün aynı saatte ayak üstü yapılan 15 dakikalık toplantılardır. Takımdaki her üye ‘Dün ne yaptım?’, ‘Bugün ne yapacağım?’, ‘İşimi engelleyen herhangi bir sorun var mı?’ sorularına cevap verir. Eğer bir problem varsa takım arkadaşlarından bu probleme yardımcı olabilecek birisi arkadaşına yardımcı olur.
3) Bileşenler/Araçlar
-Ürün Gereksinim Dokümanı: Proje boyunca yapılması gereken iş elemanlarının basit bir listesi.
-Sprint (Koşu) Dokümanı: Mevcut sprintteki ürün gereksinim dokümanı.
-Sprint Kalan Zaman Grafiği: Scrumda geçen zamanı ve kalan planlı zamanı gösteren grafik.
Scrum’ın Popülerliği:
Karmaşık yapıları basite indirgeyerek, ürün sahibi ile yapılan toplantıların ardından gereksinimleri anlaşılır bir hale getiren, ürün geliştirme metodu scrum ekip çalışmasına da önem verir. Ekip arasındaki iletişimi ve motivasyonu yukarı çeken bir metot olması da şirketler için artılarından bir tanesidir. Günlük yapılan kısa toplantılar ile de kontrolleri sağlayan metot hata ve takım arasındaki iletişim kopukluklarına da engel olur. Bu yüzden scrum metodu yazılım geliştiriciler açısından oldukça popüler ve kullanışlıdır.
Kaynak:
https://medium.com/@secilcor/scrum-nedi%CC%87r-6a4326951dd8
https://www.youtube.com/watch?v=SV6CfXWCKSo
Doç. Dr. Resul DAŞ Yazılım Tasarım ve Mimarisi ders notları
Doç. Dr. Güray YILMAZ Yazılım Mühendisliği Yazılım Geliştirme Yaşam Döngüsü ders notları
Doç. Dr. Deniz KILINÇ Yazılım Mühendisliği Temelleri ders notları
