Bu çalışmada Kodla ve Düzelt (Code and Fix), Çağlayan Modeli (Waterfall Model), V Modeli (V-shaped Model), Evrimsel Geliştirme (Evolutionary Development), Prototipleme (Protyping), Spiral Model, Formal Sistem Geliştirme (Formal System Development), Yeniden Kullanıma Yönelik Geliştirme (Re-use based development), Artımlı Geliştirme (Incremental Development), Birleşik süreç (Unified Process) ve Çevik Modeller (Agile Programming) yazılım süreç modelleri karşılaştırılmıştır. Karşılaştırma en iyi modeli belirlemekten çok her modelin avantaj ve dezavantajlarını belirli kriterler doğrultusunda değerlendirme şeklinde yapılmıştır. Çalışma sonucunda elde edilen veriler doğrultusunda bazı önemli kriterlere göre tablo oluşturularak karşılaştırma yapılmıştır.
GİRİŞ
Büyük ve karmaşık sistemler geliştiren organizasyonların ürün geliştirme süreçlerini tanımlayıp, sürekli iyileştirmesi gerekmektedir. Kalitesiz ürün geliştiren organizasyonlar itibar, müşteri ve gelir kaybı riski ile karşılaşabilir ve hatta organizasyonun geleceğini tehlikeye atabilirler. Ancak bu modeller sayesinde planlı çalışmak ve yazılım projesini en iyi şekilde gerçekleştirmek mümkün olacaktır.
YAZILIM SÜREÇ MODELLERİ
Kodla ve Düzelt (Code and Fix) Model
Bu model genellikle resmi olmayan bir ürün fikriyle başlar ve program ürün “hazır” olana kadar ya da gerekli zaman bitene kadar kodlama yapılarak devam eder. (Şekil 1)
Şekil 1. Kodla ve Düzelt Modeli [1]
Avantajları
Herhangi bir planlamaya ihtiyaç duyulmaz
Çok küçük projelerde ya da kısa ömürlü prototiplerde uygulanabilir
Program aşamaları çabuk geçilir
Uzman görüşüne ihtiyaç düşüktür herkes bu modeli kullanabilir [1]
Dezavantajları
Kontrollü değildir.
Kaynak planlaması yoktur
Bitiş süresi belli değildir
Hataların bulunması ve doğrulaması zordur
Kodları düzeltmek maliyetli olabilir
Kodlar kullanıcının ihtiyacını karşılamayabilir
Kodlar sonradan değiştirmek için planlanmadığından esnek değildir, değiştirilmesi zordur [1]
Çağlayan Modeli
Şelale yönteminde yazılım geliştirme süreci analiz, tasarım, kodlama, test, sürüm ve bakım gibi safhalardan oluşur. Geleneksel yazılım metotlarında bu safhalar şelale modelinde olduğu gibi lineer olarak işler. Her safha, başlangıç noktasında bir önceki safhanın ürettiklerini bulur. Kendi bünyesindeki değişikler doğrultusunda teslim aldıklarını bir sonraki safhanın kullanabileceği şekilde değiştirir. (Şekil 2) [2]
Şekil 2. Şelale Süreç Modeli [2]
Avantajları
Kullanımı ve anlaması basittir
Yönetimi kolaydır
Projenin safhaları ayrı olduğundan iş bölümü ve iş planı projenin en başında net bir şekilde bellidir. Bu durum projenin yönetimini de oldukça kolay hale getirir.
Şelale Modeli çok küçük ve gereksinimleri çok iyi anlaşılmış projelerde iyi çalışır. [1],[2]
Dezavantajları
Karmaşık ve nesne yönelimli projeler için uygun değildir
Devam eden ve uzun projeler için zayıftır
Projede oluşabilecek her türlü değişime elverişsiz, katı bir modeldir. Yapılan her değişiklik maliyeti büyük oranda arttırır.
Müşteri memnuniyetini sağlamak çok zordur çünkü gelişim ve değişime açık bir model değildir.
Model safhalardan oluştuğu için ürün son safhada tamamlanır, gereksinimlerin iyi tanımlanmadığı müşterinin ne istediğinin anlaşılmadığı bir projede bu durum projenin bittikten sonra iptal edilmesine ve başka gerginliklere sebep olmaktadır.[1],[3]
V Modeli
V-model(yazılım geliştirme) şelale(waterfall) modelinin gelişmiş hali olarak düşünülebilecek bir yazılım geliştirme süreci sunar. Doğrusal bir yönde ilerlemek yerine, süreç adımları kodlama evresinden sonra yukarıya doğru eğim alır ve tipik V şeklini oluşturur. V-Model geliştirme yaşam çevriminin her bir evresi arasındaki ilişkileri gösterir. Yatay ve dikey açılar zaman veya projenin tamamlanabilirliğini ve soyut seviyeyi gösterir. (Şekil 3) [5]
Şekil 3. V Yazılım Geliştirme Modeli
Avantajları
Verification ve validation planları erken aşamalarda vurgulanır
Verification ve validation sadece son üründe değil tüm teslim edilebilir ürünlerde uygulanır.
Proje yönetimi tarafında takibi kolaydır
Kullanımı kolaydır [6]
Dezavantajları
Aynı zamanda gerçekleştirilebilecek olaylara kolay imkan tanımaz
Fazlar arasında tekrarlamaları kullanmaz
Risk çözümleme ile ilgili aktiviteleri içermez
Yazılım da diğer sistemler gibi zamanla evrimleşir
Geliştirme devam ettikçe iş ve ürün gereksinimleri de değişkenlik gösterebilir
Son ürüne ulaşma düz bir çizgi ile ifade edilemez [6]
Evrimsel Geliştirme (Evolutionary Development)
İlk tam ölçekli modeldir. Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir (banka uygulamaları). Her aşamada üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler. Pilot uygulama kullan, test et, güncelle diğer birimlere taşı. Modelin başarısı ilk evrimin başarısına bağımlıdır. (Şekil 4) [7]
Şekil 4. Evrimsel Geliştirme Metodu
İki çeşit evrimsel geliştirme vardır:
Keşifçi geliştirme (exploratorydevelopment)
Hedef: Müşterinin gereksinimlerini incelemek için müşteri ile çalışıp son sistemi teslim etmek
İyi anlaşılan gereksinimlerle başlanmalıdır
Atılacak prototipleme(throw-awayprototyping)
Hedef: Sistem gereksinimlerini anlamak
Tam anlaşılmamış gereksinimlerle başlar [6]
Avantajları
Kullanıcıların kendi gereksinimlerini daha iyi anlamalarını sağlar
Sürekli değerlendirme erken aşamalardaki geliştirme risklerini azaltır
Hatalar azalır [6]
Dezavantajları
Sürecin görünürlüğü azdır (düzenli teslim edilebilir ürün yoktur)
Sistemler sıklıkla iyi yapılandırılmaz (sürekli değişiklik yazılımın yapısına zarar verir)
Bakımı zordur
Yazılım gereksinimini yenilemek gerekebilir [6]
Prototipleme (Prototyping)
Gereksinimler hızlıca toplanarak işe başlanılır. Geliştiriciler ve kullanıcılar aynı masa etrafında buluşarak yazılımdan elde edilecek bütün çıktılara, bu çıktılar için gerekli girdilerin nasıl sağlanacağına, nasıl korunacağına, hangi işlemlere uğrayacağına karar verirler. Daha sonra hızlıca yapılan bir tasarım ile yazılımın kullanıcıya yansıyacak yönünü aktaran bir ilk örnek üretilir. Prototip kullanıcının kullanımına ve değerlendirilmesine sunulur. Bu değerlendirmelere bakılarak ilk örnek üzerinde gerekli değişiklikler yapılır. Prototipin yeni hali kullanıcı tarafından yeniden değerlendirilir. Böylece kullanıcının istediği yazılıma iyice yaklaşılmış bir ilk örnek üzerinde yazılımın neler yapacağı konusunda kullanıcı ile anlaşmaya varılır. Doğrusal modelin döngüsel versiyonudur. Bu modelde, gereksinim analizi ve prototipleme için tasarım yapıldıktan sonra, geliştirme süreci başlatılır. Prototipleme yaratıldıktan sonra, müşteriye değerlendirme için verilir. Müşteri paketi test eder ve düşüncelerini, ürünü müşterinin tam beklentilerine göre düzenleyen geliştiriciye iletir. Sınırlı sayıdaki yinelemelerden sonra, son yazılım paketi müşteriye verilir. Bu metodolojide, yazılım müşteri ve geliştirici arasında periyodik bilgi gidip gelmeleri sonucunda gelişir.(Şekil 5)
Şekil 5. Prototipleme Yaşam Döngüsü [6]
Avantajları
Kullanıcı sistem gereksinimlerini görebilir
Karmaşa ve yanlış anlaşılmaları engeller
Yeni ve beklenmeyen gereksinimler netleştirilebilir
Risk kontrolü sağlanır [6]
Dezavantajları
Belgelendirmesi olmayan hızlı ve kirli (quick and dirty) prototipler
Prototip hedefleri net değilse kod hackleme ya da jenga başlar
Düzeltme aşaması atlanırsa, düşük performansa yol açar
Müşteri prototipten de son ürün gibi görünüm ve etki bekler.
Spiral Model
Sarmal modeli aynı safhalara geri dönülmesinin bir zorunluluk olduğunu vurgular, Sarmal modeli şelale modelinde yok sayılan riskleri göz önünde bulundurur, Proje çevrimlere ayrılır ve her bir çevrimin riskleri ayrı ayrı ele alınır. Çağdaş modellere son derece yakındır.
Planlama
Üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen ara ürün ile bütünleştirme
Risk Analizi
Risk seçeneklerinin araştırılması ve risklerin belirlenmesi
Üretim
Ara ürünün üretilmesi
Kullanıcı Değerlendirmesi
Ara ürün ile ilgili olarak kullanıcı tarafından yapılan sınama ve değerlendirmeler
Risk Analizi Olgusu ön plana çıkmıştır. Her döngü bir fazı ifade eder.
Şekil 6. Spiral Model [8]
Avantajları
Kullanıcılar sistemi erken görebilirler
Geliştirmeyi küçük parçalara böler. En riskli kısımlar önce gerçekleştirilir.
Pek çok yazılım modelini içinde bulundurur.
Riske duyarlı yaklaşımı potansiyel zorlukları engeller
Seçeneklere erken dikkate odaklanır
Hataları erken gidermeye odaklanır
Yazılım-donanım sistemi geliştirme için bir çerçeve sağlar [5]
Dezavantajları
Küçük ve düşük riskli projeler için pahalı bir yöntemdir
Komplekstir (karmaşık)
Spiral sonsuza gidebilir
Ara adımların fazlalılığı nedeniyle çok fazla dokümantasyon gerektirir.
Büyük ölçekte projeler
Kontrat tabanlı yazılıma uymaz
Yazılımın içten geliştirileceğini varsayar
Kontrat tabanlı yazılımlar adım adım anlaşma esnekliğini sağlamaz
Öznel risk değerlendirme deneyimine dayanır
Yüksek riskli öğelere yoğunlaşmak, yüksek riskli öğelerin doğru belirlenmesini gerektirir. [5]
Formal Sistem Geliştirme (Formal System Development)
Formal Sistem Geliştirme Modeli yazılım tasarım ve gerçekleştirmesiyle ilgili matematiksel bir tekniktir. Bu modelin temelinde karmaşık sistemleri geliştirme ve program geliştirmeye destek yatar. Formal Sistem Geliştirme Metodu kullanıcı sistemi kullanmaya başladığında karşısına çıkan belirtim hatalarını minimize eder. [8]
Formal belirtim, tasarım ve geçerleme kullanarak yazılımda doğruluğun geliştirilmesini vurgular. Yazılım artımlarla geliştirilir. Sürekli tümleştirme vardır ve fonksiyonellik tümleştirilen yazılım artımları ile artar. Felsefesi pahalı hata ayıklama işlemini engellemek için kodu ilk yazarken doğru yazmak ve test aşamasından doğruluğunu sağlamaktır. [6]
Avantajları
Yazılımdaki belirsizlikleri, eksiklikleri ve uyumsuzlukları saptar.
Hatasız yazılım geliştirme imkanları sunar.
Her iterasyondan sonra aşamalı olarak artan efektif çözümler sunar.
Karmaşık değildir.
Dezavantajları
Çok zaman alan ve pahalı bir yöntemdir.
Kullanımı esnasında teknik olmayan personelle iletişim mekanizması zor işler.
Sadece birkaç geliştirici bu modelin uygulamasıyla ilgili temel bilgilere sahip olması için yaygın eğitim gerektirir.
Yeniden Kullanıma Yönelik Geliştirme (Re-use based development)
Organizasyon tarafından daha önce hazırlanmış veya dışarıdan temin edilmiş yazılımların (veya yazılım parçalarının) kullanılması ile geliştirme yapılması son yıllarda popülaritesi artan bir yaklaşımdır. Organizasyonların olgunlukları arttıkça, bu tür uygulamalar yapabilmek için alt yapı kurulmuş olmaktadır. (Şekil 7) [10]
Şekil 7. Yeniden Kullanıma Yönelik Geliştirme döngüsünün adımları [11]
Avantajları
Kaynak kontrolü mümkündür
Maliyet denetimi yapmak mümkündür
Basit ve anlaşılırdır
Önceden oluşturulmuş sınıflar tekrardan kullanılabilir
Kısa sürede yazılım geliştirilebilir [12]
Dezavantajları
Gereksinimleri anlamak güçtür
Pahalıdır
Uzmanlık gerektirir
Başarım garantisi yoktur
Artımlı Geliştirme (Incremental Development)
Eğer bir müşterinin ürünlerinde değişikliğe ihtiyaçları varsa, artımlı model ihtiyaç olan bu değişikliğe ayak uydurur.[14] Artırımsal model bir takvime bağlı olarak yazılımı kesim kesim geliştirip teslim etmeye dayanır. Her bir yeni kesim öncekinin üstüne bazı ek işlevlerin eklenmesini öngörür. Artırımsal model yazılım geliştirmenin kısıtlı sayıda çalışanla işin yapılmasını sağlama gibi bir üstünlüğü vardır. Ayrıca çalışanlar da her artırım geçildiğinde uygulama alanına ilişkin daha çok deneyim kazanmış olurlar. [13] Bu modelde bir taraftan üretim bir taraftan da kullanım yapılır. (Şekil 8) Önceki modellerde ürünlerdeki değişiklikler göz önünde bulundurulmaz. Bu model doğal olarak yinelemelidir. Yeniden kullanılabilir bir ürün, fonksiyonellik sağlamış bir şekilde tüm döngülerin sonunda ortaya çıkar.[15] (Şekil 9)
Şekil 8. Artımlı Geliştirme Modeli
Şekil 9. Artımlı Geliştirme Modeli [15]
Avantajları
Sistem için gerekli olan gereksinimler müşterilerle belirlenir.
Gereksinimlerin önemine göre teslim edilecek artımlar belirlenir
Öncelikle en önemli gereksinimleri karşılayan çekirdek bir sitem geliştirilir.
Erken artımlar prototip gibi davranarak, gereksinimlerin daha iyi anlaşılmasını sağlar
Tüm projenin başarısız olma riskini azaltır
En önemli sistem özellikleri daha fazla sınanma (test edilme) imkanı bulmuş olur.
Divide and Conquer (Böl ve Yönet) yaklaşımıdır [6]
Dezavantajları
Artımları tanımlamak için tüm sistemin tanımlanmasına ihtiyaç vardır
Gereksinimleri doğru boyuttaki artımlara atamak bazen zor olabilir.
Deneyimli personel gerektirir
Artımların kendi içlerinde tekrarlamalara izin vermez
Birleşik süreç (Unified Process)
Nesneye dayalı yazılım geliştirmek için var olan yöntemlerin deneyimler sonucu kabul gören en iyi özellikleri bir araya getirilerek tümleştirilmiş yazılım geliştirme süreci (The Unified Process - UP) oluşturulmuştur.[6] Yinelemeli, arttırmalı ve evrimsel aynı zamanda da risk güdümlüdür.(Şekil 10) [16]