Yazılım Süreç Yönetim Modelleri ve Karşılaştırılması

 ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​​​ 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]

Şekil​​ 10. Birleşik Süreç Modeli [16]

Birleşik süreçte yazılım geliştirme aşamaları şu şekildedir (Şekil 11):

• Başlangıç: Vizyon kararı, fizibilite çalışması, tamam ya da devam kararı.

• Ayrıntılandırma: Daha gerçekçi çözümleme, çekirdek yapının ve yüksek riskli kısımların yinelemeli olarak oluşturulması.

• Tamamlama: Daha az riskli ve düşük öncelikli kısımların yinelemeli olarak gerçeklenmesi.

• Yayım: Beta testleri, piyasaya sürme çalışmaları.

Şekil​​ 11. Birleşik Süreç Modelinin aşamaları.

• • • Avantajları​​ 

• Değişen isteklere uygunluk

• Erken geri besleme

• Büyük sistemlerde çözme kolaylığı

• Her iterasyonda deneyim kazanılması

• Risklerin erken giderilmesi

• Erken ürün elde etme ve takımda moral yükselmesi[6]

• • • Dezavantajları

• Risk yönetimi zayıftır

• Dokümantasyon yükü ağır olduğundan pahalı olabilir

• Karmaşıktır [17]

• • Çevik Modeller ( Agile Programming)

İteratif geliştirme temelli bir grup yazılım geliştirme metodolojisine dayanır. Burada gereksinimler ve çözümler kendinden örgütlü olan farklı grupların ortak çalışmasıyla olgunlaşır. Agile metotları genellikle sık denetim ve adaptasyonun teşvik edildiği disipline edilmiş bir proje yönetim sürecini, takım çalışmasının, kendinden örgütlenmenin ve izlenebilirliğin özendirildiği liderlik felsefesini, kaliteli yazılımların hızlı biçimde geliştirilmesinin hedeflendiği en iyi mühendislik uygulamalarını ve yazılım geliştirme ile müşteri ihtiyaçlarını ve firma amaçlarını yan yana getiren business yaklaşımı destekler.​​ Agile metotları bir yazılım geliştirme yaklaşımı değil, geliştirme süreçleri topluluğudur.​​ (Şekil 12) [18]

Şekil​​ 12. Çevik Model

Çevik yazılım (Agile Development) bir yandan bir değer sistemini, diğer yandan da somut yazılım metotlarını içerir. Çevik yazılıma, yazılım sektöründe yeni bir filozofi akımı, ya da yeni bir yazılım meta modeli olarak bakabiliriz. Bu yeni filozofinin somut örnekleri arasında Extreme Programming, Scrum ve Lean Development bulunmaktadır.

Değerler:

• Süreç ve araçlar arası etkileşim

• Kapsamlı dokümantasyon üzerinden yazılım geliştirme

• Uzlaşılan taahhüt üzerinden müşteriyle birlikte çalışma

• Değişiklik yönetimini plan üzerinden yönetmek

Prensipler:

• Teslimatı hızlı ve aralık yaparak müşteri memnuniyeti sağlamak

• Çalışan yazılımın aylar yerine haftalar süren zamanda teslim etmek

• Sürecin esas değerlendirme kriteri çalışan sistemdir.

• Gereksinimlere sonradan eklenen değişiklikler mutlaka dikkate alınır.

• Business ve teknik ekip arasında sıkı ve günlük çalışma.

• En iyi iletişim yolu yüzyüze görüşme kabul edilir.

• Proje güvenilir ve motivasyonu yüksek kişiler üzerine kurulur

• Teknik başarı ve iyi tasarıma düzenli iltifat

• Basitlik

• Kendinden örgütlü takımlar

• Değişen koşullara adaptasyon

• • • Avantajları

• İnsanın doğal eğilimine çok yatkındır öğrenim gerektirmez adaptasyon hızlıdır.

• Kısa döngüler dolayısı ile takım elemanlarında motivasyon çok yüksektir. Verim artışı yaşanır.

• Sık çıktı üretip geri besleme aldığından kaynağı müşteri ihtiyaçlarına ve sonuca kanalize etmeye odaklanır.

• Plan aşamasında ayrıntılı plan yerine iterasyonun planı yapılır.

• Değişime açıklık ve esneklik en üst düzeydedir.

• Sürdürülebilir Kalite

• Proje planlama ve yürütme bir arada

• Takım oyunu

• • • Dezavantajları

• Kurumsal bir yapıda uygulaması gerçekten zor.

• Dökümantasyon hakkında ki taşları yerinden oynatan yaklaşımı.

• Sürekli değişen ihtiyaçlar dolayısı ile aşırı çalışma.

• Ürünün başarısı = projenin başarısı dolayısı ile kariyer riski

• Takım üzerindeki hedef baskısı

•  

• KARŞILAŞTIRMA

Tablo​​ 1a. Yazılım süreç modellerinin karşılaştırılması [6],[12],[15],[20]

Tablo 1b. Yazılım süreç modellerinin karşılaştırılması​​ [6],[12],[15],[20]

Tablo 1c. Yazılım süreç modellerinin karşılaştırılması​​ [6],[12],[15],[20]

• TARTIŞMA VE SONUÇ

Karşılaştırma sonucu​​ anlaşılmıştır ki​​ yazılım süreç modelleri tamamıyla birbirinden ayrı değildir ve çoğu zaman beraber kullanılır. Yazılım süreç modelleri geliştirilecek yazılım türüne ve kullanım alanına göre seçilmelidir. Yazılım süreç modelinin seçimi için modelin oluşabilecek riskleri tolare edebilme kapasitesi, projenin büyüklüğü, projenin karmaşıklığı, gerçekleştirecek kurumun yapısı, zaman, maliyet gibi kriterlere dikkat edilmelidir. Bu çalışma genel bir değerlendirme çalışması olduğundan ürettiği sonuçlar ancak genel bir çerçevede geçerlidir. Yapılacak projede hangi süreç modelinin kullanılacağını belirlemekten çok bu belirleme çalışmasının girdilerinden biridir.​​ Günümüzde en çok kullanılan​​ model Çevik Modeldir.(Şekil 13) Kısa sürede, esnek bir şekilde geliştirilerek, yüksek başarımla sonuçlanan bir model olduğundan en çok tercih edilen model olması muhtemeldir.​​ 

Şekil 13. Yazılım Geliştirme Süreç Modellerinin kullanım oranları [21]

• REFERANSLAR

• http://www.slideshare.net/preetimishra14661/process-models-40421019

• Yagup Macit, Eray Tüzün, "Uygulama Yaşam Döngüsü Yönetimi Karşılaştırmalı Süreç İncelemesi", 9’uncu Ulusal Yazılım Mühendisliği Sempozyumu, 2015

• Ayşe Betül Karagöz, Fatma Molu, "Finans Sektörü Yazılım Süreçlerinde Şelale Modelinden Scrum Modeline Geçiş", 2nd Internatıonal Symposium On Innovatıve Technologıes In Engıneerıng And Scıence, 2014

• http://www.slideshare.net/MesutGne/software-development-life-cycle-yazlm-gelitirme-yaam-dngs

• https://tr.wikipedia.org/wiki/V-Model_[Yaz%C4%B1l%C4%B1m_geli%C5%9Ftirme)

• http://ceng.gazi.edu.tr/~hkaracan/source/YPY_H3.pdf

• http://slideplayer.biz.tr/slide/2806563/

• http://newton.cs.concordia.ca/~paquet/wiki/images/e/ea/Spiral_model.gif

• http://ecomputernotes.com/software-engineering/formal-methods-model

• Şeyda Ocak, Medine Yıldıztekin, "Güvenli Yazılım Geliştirme Süreç Modellerinin Karşılaştırılması Uygulamaları", Elektrik-Elektronik Bilgisayar Sempozyumu, 2011

• http://www.robabdul.com/softwaredevelopment/software-development-cycle-for-data-management-system/

• Sanjana Taya, Sheveta Gupta, "Comparative Analysis of Software Development Life Cycle Models", International Journal of Computer Science and Technology Vol. 2, Issue 4, 2011

• L.Alexander and A. Davis, 1991. “Criteria For Selecting Software Process Models”. In Proceedings of COMPSAC’91 Tokyo, Japan, 09-11-1991 to 09.13.1991, pp. 521-528

• Craig Layman and Victor Basili, “Iterative and Incremental Development: A Brief History”, IEEE Computer, 2003.

• Prateek Sharma, Dhananjaya Singh, "Comparative Study of Various SDLC Models on Different Parameters", International Journal of Engineering Research, 2015

• Buzluca, F. (2010) Yazılım Modelleme ve Tasarımı ders notları (http://www.buzluca.info/dersler.html)

• https://www.cs.odu.edu/~zeil/cs350/f14/Public/processModels/

• http://www.isanalizinedir.com/index.php?option=com_content&view=article&id=54:agile&catid=39:yazilim-gelistirme-metodoloji&Itemid=56

• http://www.slideshare.net/okkesemin/agile-proje-ynetimi-10625113

• Amlani,Radhika ​​ D., "Analysis ​​ and ​​ comparative ​​ study ​​ of ​​ various software development process models", thesis PhD, Saurashtra University, 2013

• Factors Affecting the Choice of Software Life Cycle Models in the Software Industry-An Empirical Study Journal of Computer Science 8 (8): 1253-1262, 2012ISSN 1549-3636 © 2012 Science Publications